Healthcare & care
Connect the people, services,
information and decisions
behind care.
ComplexityConnected care
Healthcare and care organisations coordinate people, referrals, services, capacity, partners, finance and information while front-line teams need to remain focused on the people they support. We help connect those processes through Microsoft business applications, data, automation and purpose-built solutions where the operating requirement fits.
Care is delivered by people. The operating model around care should make work easier to coordinate, clearer and more visible.
Who this is for
Our strongest fit is care, hospice, community and clinical-service coordination.
Microsoft business applications can connect referrals, services, capacity, partners, finance and information around specialist clinical systems. That is the proposition, stated plainly.
- Care providers
- Hospices
- Specialist care services
- Community care
- Supported living
- Residential care
- Charitable and community healthcare services
- Relevant clinical-service coordination
- Multi-service care organisations
What we do not claim
We do not claim broad acute-hospital capability, electronic patient or health record delivery, diagnostic capability, prescribing, medication administration, clinical certification, regulatory approval, medical-device status, NHS assurance or named national interoperability capability. Where a requirement sits outside what we can genuinely support, we say so during qualification rather than after contract.
The boundary, stated early
Microsoft business applications can coordinate the service around care.
Specialist clinical platforms should retain clinical authority where that is their role. Establishing this before design prevents the most expensive kind of misunderstanding.
Coordination and business applications may support
- Referral
- Relationship
- Service workflow
- Case
- Communication
- Capacity visibility
- Tasks
- Operational information
- Finance
- Reporting
- Integration
Specialist clinical systems may remain authoritative for
- Specialist clinical records
- Prescribing
- Medication
- Diagnostics
- Treatment
- Other specialist clinical capability
This is not an exhaustive clinical product list. It is the principle that decides where authority sits.
Service models
Which operating model is this?
The service model changes the answer more than the sector label does. This is orientation, not an automatic technology selection.
Care provider
Residential, supported living, domiciliary or specialist care where referral, placement, capacity, staffing and service delivery drive the operating model.
Hospice or specialist care service
Specialist services where referral, assessment, coordination, family involvement and partner working sit alongside specialist clinical systems.
Community or charitable health service
Community, wellbeing or charitable services where funding, service definition and reporting to funders matter as much as delivery.
Multi-service care group
Several services or entities under one organisation, where consistency, shared information, capacity across services and group reporting become the pressure.
Healthcare service provider or clinic
Considered where the requirement is service coordination, relationships, administration and finance rather than specialist clinical capability.
Public or commissioned care service
Services delivered under commissioning arrangements, where contract, eligibility, evidence and reporting obligations shape the operating model.
Other, or not sure
Not every organisation fits a label. Describing the service is more useful than choosing a category, and the qualifier allows for that.
The care reality
The person experiences one journey. The organisation may coordinate dozens of processes behind it.
Referral, person, family, assessment, care team, service, capacity, location, appointment, case, partner, funding, documents, communication, incident, outcome and reporting all depend on each other.
The journey starts before the person arrives
A referral carries need, priority, history and missing information long before the service formally begins.
Care is coordinated, not just delivered
Assessment, planning, teams, appointments, partners and reviews all have to line up around one person.
Capacity decides what is possible
Places, appointments, teams, skills, locations and time set the limit on what the service can actually take on.
Partners are part of the service
Local authorities, health organisations, charities and commissioned providers hold parts of the same journey.
Sensitive information needs control
Not everyone involved in care should see the same record, and access has to be explainable afterwards.
Front-line capacity is valuable
Avoidable administration competes with time available for service delivery.
When those processes are disconnected
- Information gets repeated
- Staff chase updates
- Handoffs become harder
- Capacity is difficult to understand
- Families receive inconsistent information
- Management reporting becomes manual
- Front-line staff spend more time administering the service
The technology should organise the complexity around care. It should not add complexity to delivering it.
- Person
- Service
- Care team
- Capacity
- Partner
- Finance
- Data
The operating model
Referral to outcome, held as one journey.
Care organisations may coordinate these stages across several teams and systems. The objective is that the journey remains visible and owned at every step.
Referral
Need entering through a controlled route, with source, reason, priority and supporting information.
Triage and review
What has been provided, what is missing, who owns it and what has to happen next.
Assess
The appropriate professional reviewing need, history, risk and relevant circumstances.
Plan
Needs, goals, actions, responsible people, service and review dates recorded in one place.
Coordinate
Teams, tasks, appointments, documents and partner actions connected to the same case.
Deliver
The service provided, with activity, communication and changes recorded as they happen.
Review
Progress, changes in need, incidents and relevant outcomes captured against the person.
Outcome
What the service achieved, described in the organisation's own terms rather than a generic metric.
Learn
Demand, capacity, waiting and service patterns visible to leadership without a monthly rebuild.
CMS, CRM or specialist system
CMS should be selected because the service operating model fits it, not because the organisation works in healthcare.
Three genuinely different answers. Choosing between them honestly is more valuable than defaulting to any one of them.
Dynamics 365 CRM
Potentially appropriate where the requirement is primarily relationship and service workflow.
- People and organisations, referrals, cases and relationships
- Communication, activities and general service workflow
- Useful where the operating requirement is coordination rather than a developed care-service model
InteliSense CMS
Potentially appropriate where the developed care-service model is required.
- Referral, assessment, service and care context, plans and incidents
- Safeguarding workflow, capacity, family and representative communication
- Service reporting, assessed against the organisation's actual service model
Specialist clinical platform
Appropriate where specialist clinical capability or clinical authority dominates.
- Specialist clinical records, prescribing, medication, diagnostics and treatment
- Coordination can be built around the specialist system rather than replacing it
- Do not replace specialist systems simply to create architectural neatness
Data minimisation
Bring together the information needed for the service decision.
Do not copy sensitive information into another system simply because integration makes it technically possible.
Asked of every material information domain
- 01Purpose
- 02Authority
- 03Minimum information
- 04Access
- 05Sharing
- 06Retention
- 07Audit
Connected person and service context is the objective. We avoid claiming a single patient record, a single source of truth or one complete record unless a specific domain has genuinely been designated authoritative.
Referral, assessment and person context
Give the right people the information needed to make the next decision.
The platform supports professional decision-making. It does not replace professional judgement.
- Referral source, person, reason, need, priority and service requested
- Supporting information, documents, contact details, status and next action
- What has been referred, who owns it and what information is missing?
- The care journey often begins before the person enters the service.
Capacity
Availability is not automatically service capacity.
An open place, a free slot or an unassigned worker is availability. Service capacity depends on the conditions the organisation applies to it.
Contextual factors may include
- Staffing
- Skills and competency
- Service rules
- Dependency
- Location
- Appointments
- Resource
- Other organisation-defined conditions
Exception states matter as much as availability
- Available
- Waiting
- No capacity
- Information missing
- Review required
Demand is difficult to manage when capacity is invisible. We do not automate final care-capacity, admission or placement decisions. Deeper capacity capability is qualified on CMS.
Scheduling and workforce
A scheduling requirement should be qualified before choosing a system.
Service scheduling, Field Service and specialist workforce platforms solve different problems. Choosing between them early avoids an expensive correction later.
Service and appointment scheduling
Appointment, visit, service, location, team and duration held alongside the service being delivered. Potentially CMS, CRM or a focused Power Platform application.
Field Service
Considered only where the operating model genuinely resembles work order, resource, travel and mobile field execution rather than care scheduling.
Workforce and rostering
A specialist workforce platform may remain authoritative for shifts, contracted hours, skills and compliance, with deliberate integration rather than duplication.
A service plan only works when the people and capacity exist to deliver it. That is a qualification question, not a product preference.
Partner and multidisciplinary working
Partner working is an information-sharing decision before it is a portal decision.
Local authorities, health organisations, charities, community and commissioned providers hold parts of the same journey. Partner working needs controlled information sharing, not uncontrolled access.
No direct access
Controlled communication and document exchange. The partner receives what they need without entering the platform.
Form or portal
Purpose-specific structured external interaction: referral submission, status, requested information or a defined update.
Direct application access
Only where identity, security, licensing and operating need justify it, with access scoped to what the role genuinely requires.
System-to-system integration
Where the partner already runs its own operational system and the exchange should happen between systems rather than people.
Safeguarding
The platform can support the organisation's safeguarding process.
It does not determine what constitutes a safeguarding concern or replace professional accountability. We do not claim safeguarding compliance and we do not automate high-impact decisions.
The organisation owns
- Safeguarding policy
- Thresholds
- Escalation requirements
- Statutory processes
- External referral requirements
- Professional decisions
The platform may support
- Recording
- Ownership
- Workflow
- Escalation
- Evidence
- Status
- Audit
Incidents and concerns
Clear ownership and controlled follow-through on sensitive events.
This is an organisation-defined model. We do not define regulatory or clinical incident requirements on your behalf.
Incident
The event recorded as the organisation defines it, with the information the process requires.
Owner
A named person accountable for the next action, visible rather than implied.
Immediate action
What was done at the time, recorded against the event rather than in a separate note.
Escalation
The organisation's own escalation route, applied consistently and visible to those who need it.
Review or investigation
The review the organisation requires, with the evidence attached to the record.
Follow-up
Actions arising, with owners and dates that can be tracked to completion.
Outcome
What was concluded, described in the organisation's own terms.
Closure
Closed against the organisation's criteria, with the audit position intact.
Family and representatives
Being a family member or representative does not automatically mean unrestricted access to care information.
Where family and representative involvement is part of the service, the governing position should be recorded rather than assumed.
- Relationship
- Authority
- Contact preference
- Information permitted to be shared
- Communication route
- Direct access versus communication
- Change and revocation
- Audit
Automation suits acknowledgements, reminders and status updates. Sensitive communication should keep a named human owner.
Clinical safety and assurance
Assurance requirements are identified during qualification, not assumed.
Where functionality could influence care or clinical safety, where NHS-facing requirements apply, or where specialist clinical integration is involved, additional assurance must be identified during qualification rather than assumed.
We do not claim named clinical-safety compliance, NHS approval, DTAC approval, medical-device status, regulatory marking or named interoperability capability. Where any of those are genuinely required, that becomes a qualification outcome with the accountable people involved, and it may be the reason a requirement is not one we should take.
See how CMS assurance is qualifiedInformation governance
Connected care information should not become unrestricted care information.
A concise governance position applied to every information domain that the operating model touches.
- 01Purpose
- 02Owner
- 03Access
- 04Change
- 05Sharing
- 06Retention
- 07Audit
- 08Archive and closure
Service continuity
Care still has to operate when technology is unavailable.
Downtime behaviour should be designed with the service, not discovered during an incident.
Critical service
Which services genuinely cannot pause, defined by the organisation rather than assumed.
Technology dependency
What each critical service depends on: platform, integration, network, device or partner system.
Downtime process
How work is recorded and coordinated when the platform or an integration is unavailable.
Critical information
What must remain available offline or through another route for the service to continue.
Escalation
Who is told, in what order, and what decision they are being asked to make.
Recovery
Who owns recovery, in what sequence, and how return to normal operation is confirmed.
Reconciliation
How activity recorded during downtime is brought back into the operating record afterwards.
Questions worth answering before go-live
- What happens if CMS or CRM is unavailable?
- What happens if an integration fails?
- What information must remain available?
- How is work recorded during downtime?
- How is activity reconciled later?
- Who owns recovery?
We do not publish uptime, recovery or service-level numbers without approved contractual evidence.
ERP fit
ERP fit follows the operating and financial model, not the Healthcare label.
Business Central is not the universal healthcare ERP, and organisation size is not the deciding rule.
Business Central
Potential fit where finance, purchasing, budget, project, supplier, cash and reporting requirements fit responsibly.
- Finance, purchasing, budgets, suppliers, projects, cash and reporting dimensions
- Funding and cost connected to the service being delivered
- Business Central does not manage clinical care
Dynamics 365 Finance
Potentially relevant where deeper enterprise financial governance requires it.
- Multi-entity finance, intercompany and enterprise controls
- Complex financial governance and a wider enterprise operating model
- Organisation size is not the deciding rule
Service and finance
Connect service and financial information where leadership needs the relationship.
Service information and financial information should connect without exposing financial detail to roles that do not need it. Care and clinical users do not need direct finance access.
Service demand
Referrals, waiting work and requested services expressed in the organisation's own definitions.
Capacity and resource
What the service can actually take on, and what is constraining it.
Funding and budget context
Commissioned, grant, charitable or private funding, held against the services it supports.
Cost
Staffing, supplier, property and delivery cost connected to the service rather than estimated later.
Management information
The relationship between demand, capacity, funding and cost, shown to the roles accountable for it.
Connected platform
Different processes need different systems. The operating model should connect them.
Care context, financial control and insight each need the right home, joined by deliberate integration rather than duplicated data entry.
- 01CMS or CRM may hold the service-coordination context
- 02Specialist systems may remain authoritative for clinical, workforce or other specialised information
- 03Controlled integration moves only what each system genuinely needs
- 04ERP remains authoritative for the agreed financial domains
- 05Data and insight bring demand, capacity, service and cost together
Power Platform
Referral forms, focused service applications, approvals, mobile forms, partner processes and Power Pages. Low code should simplify the service, not create an unmanaged application estate.
Power BI and Fabric
Referrals, demand, waiting, capacity, service activity, case status, incidents, outcomes and funding, reported from the operating record.
Data and AI
Knowledge retrieval, document processing, summarisation and operational analysis, with human accountability preserved.
Where do you start?
Tell us the service and the situation. We will tell you the honest route.
Four questions. It routes to a commercial route rather than a product, and CMS is treated as a solution choice rather than a route. Please keep every answer at organisation and service level.
Indicative signal
Answer the questions and we will show an honest directional signal. This is orientation rather than a clinical, regulatory or clinical-safety determination, and it never selects a platform for you. Please keep every answer at organisation and service level.
Your answers are carried through, so you will not be asked to repeat them. Final qualification is always a conversation.
Information
Better care decisions depend on information people can trust.
Information quality, reporting, security and access, and interoperability with the systems that already work.
- Duplicate person records, disconnected referrals, spreadsheet tracking and manual reporting
- Different service definitions, incomplete information, partner data and legacy systems
- Ownership, definitions, quality, access, integration, reporting and governance
- Better care decisions depend on information people can trust.
AI with accountability
Use AI to reduce information burden, not to remove human responsibility.
These are candidate use cases, not claims. We assess the available data first and say plainly where it does not support the idea.
Reduce information burden
Summarise service history and referral information, prepare case context, draft routine correspondence and extract information from documents.
Find approved knowledge
Help authorised users retrieve relevant policies, procedures, service guidance and referral criteria. AI-generated information is not clinical advice.
Potential predictive use cases
Demand pressure, capacity pressure, referral backlog, service utilisation and operational backlog, assessed against real data before anything is promised.
Human oversight follows consequence
Retrieve or summarise
AI may assist within approved information boundaries, using information the user is already entitled to see.
Draft or prepare
Drafting correspondence, preparing case context or extracting information from documents, with human review where the organisation requires it.
Administrative automation
Approved low-risk steps may execute within explicit limits: acknowledgements, reminders, task creation, status updates.
Recommend
Human oversight follows the consequence of the recommendation and the authority of the person acting on it.
High-impact care, safeguarding or clinical decision
Responsible professional authority remains central. The platform records the decision. It does not make it.
Human oversight should follow consequence, authority and the organisation's approved policy rather than one universal review step applied to everything.
Automate coordination before judgement
- Acknowledgements
- Reminders
- Task creation
- Approvals
- Document requests
- Status updates
- Referral routing
- Reporting preparation
A lower-risk starting point is often administrative coordination rather than high-impact decision-making.
What we do not present generic AI as doing
- Diagnosis
- Prescribing
- Treatment recommendation
- Autonomous clinical triage
- Safeguarding decisions
- Admission or discharge
- Clinical-risk scoring
Predictive Intelligence is treated as operational only: demand pressure, capacity pressure, referral backlog, operational backlog and service utilisation. These remain potential use cases. Current demonstrations do not prove healthcare use cases, and clinical deterioration, patient risk, diagnosis, safeguarding risk and admission suitability are not propositions we present.
Value realisation
The technology outcome is not a new care record.
It is whether the service can coordinate its work with less avoidable administration and clearer accountability.
Business or service outcome
The operating result leadership actually needs, stated before any capability is chosen.
Baseline
Where the service is now, measured in the organisation's own definitions rather than a benchmark.
Operating change
What people will do differently. Technology alone does not change the outcome.
Platform capability
The capability required to support the change, and nothing beyond it in the first release.
Adoption
Whether the change is actually being used in the live service rather than alongside it.
Evidence
The movement recorded against the baseline, in the organisation's own numbers.
Review
What the evidence justifies next: continue, adjust, extend or stop.
Operational areas worth baselining
- Referral administration
- Missing information
- Waiting-work visibility
- Ownership
- Duplicate entry
- Communication administration
- Capacity visibility
- Partner handoff
- Reporting effort
We do not claim improved patient outcomes, improved care quality, improved safety or reduced waiting times. Those are claims that require verified evidence from the organisation itself.
Commercial routes
Choose the route that fits the actual problem.
CMS is a solution choice, not a commercial route. Data & AI is a capability, not a core commercial route.
Standard Implementation
Where the operating model and platform are sufficiently understood and conventional governed implementation is appropriate.
ExploreRAPID qualification
Only where the underlying platform and bounded scope meet the approved RAPID criteria.
ExploreRAPID, used selectively
Healthcare or CMS does not automatically qualify for RAPID. RAPID applies only where the underlying scope and platform meet the approved qualification conditions. A focused CRM or Business Central requirement may qualify. A complex CMS, clinical-integration or care-transformation programme may not. We do not promise an implementation in a number of days because the organisation works in healthcare.
Explore RAPIDAfter go-live
Support keeps agreed capability operating, and the supported scope depends on the contracted service and technologies agreed. Customer Success reviews business and service priorities, evidence and value. Optimise executes justified improvement. Recovery is used where control or confidence has materially deteriorated. Each is a separately defined commercial service.
Confidence gates
Four gates before the service depends on it.
Go-live confidence should come from proving that the service can continue through the new operating model, not simply that the software is configured.
Gate 1
Qualify
Service and responsibility confidence.
Before anything is designed, the service, the problem and the boundary of professional responsibility have to be understood.
Confirmed at this gate
- Organisation and service model
- Operating problem
- Intended outcome
- Care versus clinical boundary
- Professional decisions
- Safeguarding ownership
- Specialist systems
- Critical dependencies
Decision
Proceed · Assessment · CMS qualification · Retain a specialist system · Transform first
Gate 2
Design
Platform, data and governance confidence.
Platform fit, information authority and governance are confirmed together, because a decision on one changes the others.
Confirmed at this gate
- CMS, CRM, ERP and Power Platform fit
- Authoritative information by domain
- Access
- Information governance
- Integration
- Migration
- Reporting
- Continuity
- Licensing
- Assurance
- First-release scope
Decision
Proceed · Re-scope · Retain the specialist system · Deeper assurance
Gate 3
Prove
End-to-end service proof.
The service is proven through the new operating model, including the situations that are inconvenient rather than only the ones that are tidy.
Confirmed at this gate
- Referral, review, assessment and service decision
- Capacity, coordination, delivery, review and reporting
- Missing referral information and no capacity
- Restricted access and an incident
- Safeguarding workflow and partner handoff
- Family or representative communication
- Integration failure, downtime and reporting
Decision
Proceed · Remediate · Re-test
Gate 4
Go-live
Operational go-live readiness.
Go-live confidence should come from proving that the service can continue through the new operating model, not simply that the software is configured.
Confirmed at this gate
- Active people and service users
- Referrals, assessments, plans and cases
- Appointments and capacity
- Incidents and safeguarding actions
- Partner activity and representatives
- Integrations and access
- Migrated data and training
- Continuity and support
Decision
Go · No-go · Controlled deferral
Shared responsibility
We can configure and connect the operating process.
The organisation remains accountable for the care, clinical, safeguarding and governance decisions behind it.
The customer owns
- Care and service policy
- Clinical policy where applicable
- Safeguarding policy
- Eligibility and admission rules
- Professional decision authority
- Capacity rules
- Information-governance decisions
- Lawful sharing decisions
- Retention
- Security policy
- Finance and accounting decisions
- Service definitions
- Data validation
- User acceptance testing
- Cutover
- Adoption
- Continuity
InteliSense may provide where agreed
- Process design
- Architecture
- Solution qualification
- Configuration
- Development
- Integration
- Migration
- Testing
- Reporting
- Delivery assurance
- Cutover support
- Risk visibility
Foundations
Migration, adoption, security, licensing and integration.
These carry much of the risk in a healthcare or care implementation. Each links to the discipline that owns it.
Cutover
Cutover is ready when the service can continue without losing the context staff need for the next accountable action. One large switch-over is not always required, and a phased or service-by-service approach may be the safer option.
- Active people and service users
- Referral status
- Ownership
- Next action
- Current assessments
- Plans and cases
- Appointments
- Capacity
- Incidents
- Safeguarding actions
- Partner actions
- Representative and contact context
- Critical documents
- Integrations
- Access
- Support
Leadership views
Different roles need different views of the same service.
One connected operating context, read in the way each person has to act on it.
CEO
Whether demand, capacity, service and financial sustainability are moving out of balance.
COO / service director
Referrals, waiting, capacity, case status, teams, actions, incidents and partner dependencies.
CFO
Funding, budget, cost, supplier, cash and how operational demand connects to financial pressure.
CIO / digital
Architecture, integration, security, data, technical debt, support and AI governance.
Front-line
Today's work, person context, actions, appointments, documents and the next step. Less administration, not more.
Illustrative example
A referral is received.
A simplified walk-through of one journey. It describes how the operating model behaves, not a specific customer.
- 01ReferInformation enters through a controlled route.
- 02ReviewThe team sees what has been provided and what is missing.
- 03AssessThe appropriate professional reviews the need.
- 04MatchService and capacity are considered together.
- 05CoordinateThe relevant team and partners receive actions.
- 06DeliverThe service is provided.
- 07ReviewProgress and relevant outcomes are recorded.
- 08LearnLeadership sees demand, capacity and service patterns.
The advantage is not owning more Microsoft products. It is being able to connect appropriate capabilities around the operating model, alongside the Microsoft services and specialist systems the organisation has chosen to retain.
Customer voice
Customer experience of working with InteliSense.
Customer voices
InteliSense customers
Hear our customers talk about InteliSense
Our current published customer videos evidence Dynamics delivery with InteliSense. They do not currently provide verified Healthcare & Care delivery outcomes. Healthcare-specific customer evidence will be published when the sector, engagement and approved claims have been verified.
The existence of a developed CMS proposition proves that the proposition exists. It does not prove a CMS customer implementation, a care-quality improvement, a clinical outcome, a safeguarding outcome, a capacity improvement or any healthcare customer outcome. No customer shown here is classified as Healthcare & Care in our central evidence model, and no sector experience should be inferred from any customer name.
Common questions
Healthcare and care questions we are asked.
Direct answers, including where the honest answer is that a requirement sits outside what we should take on.
Next step
Start with the service, not the software.
Tell us the organisation, the service model and what is becoming harder to coordinate. We will give an honest view on the route, the platform question and the boundary with the specialist systems you already run.
Not sure where the problem sits? Start with an assessment