Executive sponsor (organisation)
Approves the scope, owns the internal decision to proceed and resolves conflicts between departments.
Involved in: Discovery, scope sign-off, handover
Implementation
An implementation begins with scope and responsibility, not with software.
Implementations are opened by discussion with the organisation. There is no self-serve onboarding.
Process
Six stages, in order
- 1
Organisation discovery
Confirm the operating context, the workflows in question, the stakeholders involved and the boundaries of what technology should and should not touch.
- 2
Scope and responsibility review
Define in writing what PulseArc will configure and what remains with the organisation, including clinical, consent and regulatory ownership.
- 3
Data and integration assessment
Confirm which data sources are approved, what access is required, which technical dependencies exist and which privacy roles apply.
- 4
Configuration and validation
Configure the agreed environment and validate it with the organisation's own authorised users before it is relied upon.
- 5
Training and handover
Provide the agreed operational guidance, administrator instructions and the named support contacts.
- 6
Ongoing support and change management
Handle issues, configuration changes and any future modules through the approved support route.
Implementation timing, available modules, integration support, training and any service levels are confirmed in the applicable agreement. This page does not state a delivery timeline.
Governance
Governance before an environment is configured
Each of these is completed and documented with the organisation before any environment is configured.
- 1
Scope and suitability
Confirm the administrative workflow, organisation type, intended users, jurisdictions and excluded use cases.
- 2
Commercial and legal agreement
Confirm service scope, responsibilities, fees, support arrangements, confidentiality and applicable terms before any service begins.
- 3
Data and privacy assessment
Confirm the customer organisation's role, PulseArc's agreed role, categories of information, lawful basis, retention, approved sub-processors and data-transfer requirements.
- 4
Security and access design
Agree authorised administrators, user permissions, access controls, implementation dependencies and the customer's internal security responsibilities.
- 5
Integration assessment
Assess any requested system connection individually. No integration availability is implied until it is approved in writing.
- 6
Configuration and acceptance
Configure only the agreed modules and complete documented acceptance steps before operational use.
- 7
Support and review
Provide the agreed support route and review implementation boundaries as required.
PulseArc does not configure an environment, receive patient information or activate a requested module solely because an enquiry has been made. Requirements are assessed and documented with the organisation before implementation.
Before we start
What your organisation needs to have
- A named internal owner for the workflows in question
- Agreement internally on which administrative steps are actually in scope
- A nominated administrator who will manage user access
- Clarity on your own consent, privacy and regulatory position
- For any data source or system: its internal owner and your authority to use it
Afterwards
Support and change management
A single documented support route by email to the organisation's named PulseArc contact. Configuration changes, issues and any future modules are handled through that same route so there is one record of what was requested and agreed.
Support hours and response times are not published on this website. Where an organisation requires a specific commitment, it is agreed in the applicable agreement.
Artefacts
What exists on paper at each stage
An implementation is judged by its documents as much as its configuration. Each artefact below has a named owner and is held by both sides.
| Artefact | Produced | Owner | Contains |
|---|---|---|---|
| Discovery summary | After organisation discovery | PulseArc, reviewed by the organisation | Operating context, workflows in question, stakeholders and the agreed boundary of what technology should not touch. |
| Scope and responsibility statement | Before any configuration | Agreed jointly and signed | What PulseArc will configure, what remains with the organisation, and the clinical, consent and regulatory ownership split. |
| Data and access assessment | Before any configuration | Organisation system owners with PulseArc | Approved data sources, access required, privacy roles, technical dependencies and any cross-border consideration. |
| Configuration record | During configuration | PulseArc | Queues, statuses, message templates, report definitions, roles and visibility rules as configured. |
| Validation sign-off | Before the environment is relied upon | The organisation's authorised users | Confirmation from the organisation's own staff that the configuration matches the agreed scope. |
| Administrator handover pack | At handover | PulseArc, held by the organisation | Written guidance on access, queues, routine changes, the support route and the change-request process. |
People
Who needs to be in the room
Implementations stall when there is no internal owner for a decision. These are the roles an organisation should identify before discovery begins.
Operations owner (organisation)
Defines how the workflow actually runs, what 'complete' means and which rules must be reflected.
Involved in: Discovery, configuration review, validation
Nominated administrator (organisation)
Maintains the user list, grants and removes access, and raises change requests after handover.
Involved in: Configuration, handover, ongoing support
System owner (organisation)
Confirms authority over any source system and its interfaces before an integration is assessed.
Involved in: Data and access assessment
Implementation lead (PulseArc)
Runs discovery, documents scope, configures the environment and holds the single support record.
Involved in: Every stage
Start with a scope conversation.
The first discussion is about your operating context and where the boundaries sit — not a product walkthrough.