Assess Before You Build | AWS | Inference Clinical

Q: Is the Assess phase eligible for AWS MAP funding?

Yes. The Assess phase aligns directly with AWS Migration Acceleration Program (MAP) Assess phase funding. The MAP Assess phase provides partner funding of 5% of projected ARR (up to $75,000) as direct cash to offset audit costs. A Standard Assessment can be substantially or fully funded through the MAP programme.

What the Assess phase does

Evaluates the service design

What is the service trying to do? Where does it cross organisational boundaries? What responsibilities does it create? What handoffs and accountability gaps does it introduce?

Scopes the first governed boundary

Identifies the highest-value or highest-risk crossing to use as the lighthouse. This is the boundary where governance is proved first, before the organisation commits to scale.

Tests the foundation

Assesses whether the current or planned AWS environment can support lawful, auditable, clinically safe operation across the boundaries the service creates.

Defines the next step

Proceed to landing zone and lighthouse. Remediate the foundation first. Narrow the scope. Or stop and rethink. Every Assess engagement ends with a clear, bounded recommendation.

Engagement Tiers

The Assess phase is bounded and finite. It comes in three tiers, depending on the number of boundaries and the complexity of the organisation.

	Rapid Assessment	Standard Assessment	Enterprise Assessment
Scope	Single material boundary	5-8 boundaries	Full portfolio or PE-held group
Duration	2-4 weeks	4-6 weeks	10-16 weeks
Six disciplines	Condensed	Full	Full with phased boundary analysis
Co-design workshop	Findings briefing	Included	Multiple workshops
Lighthouse specification	Outline	Detailed	Detailed with sequenced programme
MAP alignment	Assessment report	Full MAP Assess documentation	Enterprise MAP case

When to use the Assess phase

Before an AWS migration involving clinical systems
Before launching a new cross-boundary healthcare service
Before scaling a pilot across multiple organisations
When legal, safety, and technical responsibilities at boundaries are unclear
When you need to identify the right first lighthouse boundary

The six disciplines

Each boundary is assessed across six disciplines. Service design establishes whether the system is governable. Legal and clinical safety constraints define what is permissible. Only then can technology, architecture, and governance design begin.

#	Discipline	What it examines	What it produces
01	Service Design	Whether the proposed pathway, operating model, and boundary crossings can support governed operation	Service boundary map, lighthouse candidate, and priority pathway risks
02	Legal and Regulatory	Constitutional domains, lawful basis, and regulatory conflicts across boundaries	Boundary-specific obligation map and legal gap analysis
03	Clinical Safety	Whether existing safety cases, hazard logs, and deployment thinking cover cross-boundary risk	Boundary hazard identification and DCB 0129/0160 gap analysis
04	Foundational Technology	Whether the environment can support secure, monitored, governed operation	Landing zone requirements and technical readiness findings
05	Future Technology and Architecture	Whether planned programmes create new unmanaged boundaries or governance debt	Roadmap alignment and build-once-use-many opportunities
06	Boundary Governance	Seven Flows maturity across each material crossing, lighthouse candidates	Maturity assessment, remediation roadmap, and lighthouse specification

Claim authority: STATUTORY Law or mandatory standard ASSURANCE EXPECTATION NHS guidance and procurement IC POLICY Inference Clinical requirement

What we examine

What the service is intended to do and which organisations it crosses
Which handoffs and responsibility transfers the pathway creates
Where responsibility becomes ambiguous or unassigned
How consent, safety, and outcome are meant to work in operation
Whether the proposed operating model is actually governable
What workarounds clinicians have adopted and what governance gaps they reveal IC POLICY

What we produce

Service boundary map
First lighthouse candidate
Priority pathway risks
Operating model gaps and boundary assumptions that must hold
First-step deployment recommendation

Why it matters

Before technology is assessed, the service itself has to make sense. A weak service design cannot be repaired by stronger infrastructure. This is structured qualitative discovery with the clinicians and operators at each boundary, producing the design inputs that governed operation, the Responsibility Ledger, and the Evidence Fabric require.

What we examine

The constitutional domains operating on each side of every material boundary. Healthcare organisations do not operate under a single regulatory framework. The obligations differ by organisation type, function, and the nature of the patient pathway crossing.

Healthcare-specific regulation

Health and Social Care Act 2012 (Section 250) - the statutory basis for information standards including DCB 0129/0160 STATUTORY
Data (Use and Access) Act 2025 (DUAA) - new information standards powers for healthcare IT systems covering functionality, connectivity, interoperability, portability, storage, access, and security STATUTORY
Care Quality Commission (CQC) registration requirements and inspection framework
Caldicott Principles and Caldicott Guardian obligations for patient confidentiality
Common Law Duty of Confidentiality governing patient information

Data protection

UK GDPR and Data Protection Act 2018 (as amended by DUAA) - lawful basis for processing, special category data (Article 9), DPIA requirements STATUTORY
DUAA amendments to automated decision-making (Article 22A) requiring meaningful human involvement, directly relevant for AI-assisted clinical pathways
National Data Guardian's 10 Data Security Standards underpinning DSPT

Financial regulation (insurer and private healthcare pathways)

FCA Consumer Duty - requiring evidence of good outcomes across provider networks STATUTORY
Solvency II and insurance contract law
FCA 2026 Insurance Regulatory Priorities including operational resilience and fair value

Device and safety regulation

MHRA - UK Medical Devices Regulations 2002 (as amended) for Software as a Medical Device (SaMD) classification
NIS Regulations (Network and Information Systems) - applicable to Operators of Essential Services in healthcare
Cyber Security and Resilience Bill - forthcoming legislation extending CAF requirements

DUAA 2025: Three provisions that change the Assess scope

Section 121 - Information standards become mandatory. NHS England can mandate specific data standards with statutory force. Organisations that do not comply face enforcement, not just procurement disadvantage. The Assess phase evaluates current standards adoption against projected mandates.

Article 6(1)(e) - Lawful basis clarification for private providers. Private healthcare providers cannot rely on the NHS's public task as their own lawful basis for processing patient data. Every cross-boundary data flow between private and NHS organisations must establish an independent legal basis. The Legal discipline maps every boundary where this applies.

Article 22A - Automated decisions on health data. New safeguards for automated processing of health data, including clinical decision support and AI triage. Organisations deploying algorithmic systems at clinical boundaries must demonstrate compliance before go-live. The Assess phase identifies where automated decision-making crosses organisational boundaries.

These three provisions do not arrive in isolation. They arrive into an environment where most organisations have not yet mapped their cross-boundary data flows, let alone assessed the lawful basis for each one.

When a patient pathway crosses a boundary between two organisations, it crosses between constitutional domains. The legal review maps these domains and identifies where regulatory obligations conflict, where data sharing agreements are absent or inadequate, where liability for clinical outcomes is ambiguous, and where consent models are insufficient for the data flows required.

What we produce

Constitutional domain map for every material boundary
Full regulatory obligation matrix mapping each boundary to applicable legislation
Data sharing agreement gap analysis
DUAA readiness assessment for forthcoming information standards
Liability exposure assessment at each boundary crossing
Consent model evaluation against actual data flow requirements (UK GDPR Article 6, Article 9, and Caldicott)
Regulatory conflict identification (where Organisation A's obligations conflict with Organisation B's)
FCA Consumer Duty evidence gap analysis (for insurer-provider pathways)

Why it matters

Legal and regulatory constraints are not optional. They are the constitutional layer that determines what is and is not permissible. Technology solutions built without understanding the constitutional domain will encounter compliance failures that cannot be resolved by engineering. The DUAA introduces new powers for the Secretary of State to mandate IT standards for healthcare - organisations building infrastructure now must design for requirements that are being defined in real time. This review must happen first because it defines the constraints within which all other disciplines operate.

What we examine

Clinical safety obligations under the full standards framework for every system involved in the pathway.

Core clinical safety standards

DCB 0129 (manufacturer clinical risk management) - legally mandated under Health and Social Care Act 2012 Section 250 for all publicly funded digital products used in direct patient care STATUTORY
DCB 0160 (deploying organisation clinical risk management) - the mirror obligation requiring healthcare organisations to assess clinical risk of systems they deploy STATUTORY
DTAC (Digital Technology Assessment Criteria, updated February 2026) - the NHS assessment framework covering clinical safety, data protection, technical security, interoperability, and usability ASSURANCE EXPECTATION
NICE Evidence Standards Framework for Digital Health Technologies - evidence requirements for effectiveness and economic impact

Safety reporting and surveillance

LFPSE (Learn from Patient Safety Events) - the mandatory patient safety incident reporting service that replaced NRLS in June 2024
MHRA Yellow Card adverse incident reporting for medical devices
Post-market surveillance obligations under MHRA framework

Medical device classification

MHRA SaMD (Software as a Medical Device) classification assessment under UK Medical Devices Regulations 2002
MHRA AI/ML guidance including the AI Airlock regulatory sandbox and machine learning transparency principles

Data integrity

ALCOA+ compliance (Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, Available) for all clinical data in audit trails IC POLICY

The review specifically examines whether existing hazard logs account for boundary-crossing risks (most stop at the organisation's edge), whether clinical safety cases address the Seven Flows at each boundary, whether Clinical Safety Officers have visibility across the full patient pathway or only within their own organisation, whether LFPSE reporting covers cross-boundary incidents, whether the minimum viable responsibility transfer (MVRT) conditions are defined for each handoff, and whether DTAC documentation covers the inter-organisational context.

What we produce

Boundary-specific hazard identification across all material crossings
Gap analysis of existing DCB 0129/0160 clinical safety cases against cross-boundary operation
DTAC compliance assessment for all digital health technologies operating at boundaries
MHRA SaMD classification review for boundary-crossing software
MVRT specification for each priority boundary
LFPSE reporting gap analysis for cross-boundary incidents
Clinical Safety Officer visibility assessment
ALCOA+ compliance assessment for clinical data traversing boundaries
NICE Evidence Standards gap analysis for outcomes measurement
Recommendations for DCB 0129/0160 compliance at the inter-organisational level

Why it matters

Most clinical safety frameworks assess systems within organisational boundaries. The space between organisations is where clinical safety cases are weakest and where patient harm from handover failures is most likely. DCB 0129 and DCB 0160 are legally mandated - compliance is not optional. Yet a 2025 study found that compliance rates across NHS organisations are alarmingly low even within organisations. At the boundary, the gap is worse. This review makes the boundary safety landscape visible for the first time and produces hazard log entries that existing frameworks miss.

What we examine

The current state of technology infrastructure on both sides of every material boundary. This review delivers engineering excellence through systematic assessment against three complementary frameworks.

AWS Well-Architected Framework (six pillars, healthcare lens) IC POLICY

Operational Excellence (clinical operational readiness) - Can existing systems support governed boundary operations? Are runbooks, monitoring, and incident response designed for cross-boundary scenarios?
Security (clinical data sovereignty) - How is patient data protected in transit and at rest? Are IAM policies, encryption, and access controls sufficient for multi-organisation operation?
Reliability (patient safety continuity) - What happens when a system at one side of a boundary fails? Is there graceful degradation for cross-boundary operation?
Performance Efficiency (clinical pathway responsiveness) - Are systems sized for the clinical workload? Can the infrastructure support real-time responsibility transfer and alert propagation?
Cost Optimisation (value-aligned cost) - Is infrastructure cost proportional to clinical value? Are there standing resources that could be event-driven?
Sustainability (long-term clinical infrastructure viability) - Is the architecture sustainable for multi-year operation? Are there vendor lock-in risks?

DSPT/CAF-aligned assessment (NCSC Cyber Assessment Framework, NHS England 2025/26) ASSURANCE EXPECTATION

Objective A - Managing security risk: governance, risk management, asset management
Objective B - Protecting against cyber attack: service protection policies, identity and access management, data security, system security, resilient networks
Objective C - Detecting cyber security events: security monitoring, proactive security event discovery
Objective D - Minimising impact of incidents: response and recovery planning, lessons learned
Objective E (NHS-specific) - Using and sharing information appropriately: Caldicott compliance, data sharing agreements, information governance

Cyber Essentials Plus baseline assessment ASSURANCE EXPECTATION

Boundary firewalls and internet gateways
Secure configuration
Access control
Malware protection
Patch management

For organisations with existing AWS workloads, this review uses the AWS Well-Architected Tool and produces findings aligned with AWS review methodology. For organisations not yet on AWS, it produces a baseline assessment that informs the migration approach. In both cases, findings are cross-referenced against DSPT/CAF requirements to ensure infrastructure decisions support regulatory compliance.

What we produce

Well-Architected aligned assessment of existing infrastructure with healthcare lens
DSPT/CAF readiness assessment with gap analysis against all five objectives
Cyber Essentials Plus readiness evaluation
Integration point inventory with risk scoring
Landing zone requirements specification (account structure, network topology, identity federation, security baseline)
Technical debt assessment for boundary-crossing systems
NIS Regulations compliance assessment (for Operators of Essential Services)
Existing workload evaluation: what migrates, what modernises, what retires

Why it matters

Clinical governance infrastructure cannot be deployed on unstable foundations. If the underlying cloud environment lacks proper isolation, monitoring, or security controls, governance invariants cannot be maintained. The 2025/26 DSPT transition to CAF-aligned assessment raises the bar significantly - organisations must now demonstrate outcome-based security, not checkbox compliance. The foundational technology review ensures the landing zone is designed to meet both AWS Well-Architected standards and NHS regulatory requirements from day one.

What we examine

Where the organisation's technology roadmap is heading and how governance infrastructure aligns with that trajectory.

Planned system replacements or migrations (EPR transitions, new clinical systems)
AI and machine learning ambitions (clinical decision support, population health, operational AI)
Remote monitoring and digital health programmes
Data platform and analytics strategy
Integration with national programmes (NHS App, NHS Login, Federated Data Platform)

The review assesses whether planned investments will create new ungoverned boundaries, whether governance infrastructure can be designed to accommodate the roadmap, and where investment in governance now prevents expensive remediation later.

What we produce

Technology roadmap alignment assessment
Future boundary map (new boundaries that planned changes will create)
Governance infrastructure requirements for planned programmes
"Build once, use many" opportunities where governance controls deployed now serve future programmes
AI readiness assessment: whether the data infrastructure supports safe, governed AI deployment (provenance, consent, audit trails)

Why it matters

Organisations making foundational infrastructure changes have a narrow window to embed governance correctly. Retrofitting governance after systems are live is dramatically more expensive and disruptive than designing it in. This review ensures the landing zone and governance infrastructure are designed for where the organisation is going, not just where it is now.

What we examine

The core Seven Flows assessment across every material boundary IC POLICY. Each boundary is scored on a five-level maturity scale (0-4) for each of the seven flows:

Identity - Is patient, practitioner, and organisation identity verifiable across this boundary?
Consent - Is consent explicit, current, portable, and evaluated at the point of action across this boundary?
Provenance - Does clinical data carry its origin, method, and integrity state across this boundary?
Clinical Intent - Is clinical reasoning preserved and accessible when data and responsibility cross this boundary?
Alert and Responsibility - Are alerts explicitly owned and is responsibility transfer bilateral and confirmed at this boundary?
Service Routing - Is routing governed by clinical criteria rather than capacity or convenience across this boundary?
Outcome - Are outcomes observable and attributable across this boundary?

Scores are adjusted for cascading dependencies. Identity failures cascade into every downstream flow. Clinical Intent failures cascade into Alert and Responsibility, Routing, and Outcome. A Level 0 in Identity with Level 3 everywhere else produces an effective maturity lower than any individual score suggests.

What we produce

Scored boundary maturity assessment for every material crossing
Cascading dependency analysis
Statutory traceability: each finding linked to the regulation it engages
Priority-ranked remediation roadmap
Lighthouse project candidate identification
Funded business case framework (linking to MAP Assess phase funding where applicable)

Why it matters

This is the assessment that no existing framework provides. CQC inspects within organisations. DSPT assesses data security within organisations. NHS audits examine processes within organisations. Nobody measures what happens between them. The Seven Flows boundary assessment makes the inter-organisational governance landscape visible, scored, and actionable.

What you get

1. A scoped view of the service and its boundaries - what the service crosses, what responsibilities it creates, where governance is absent
2. A first lighthouse candidate - the boundary where governance should be proved first
3. A scored assessment across the six disciplines - constitutional and operational, with priority-ranked findings
4. A landing zone readiness view - whether the current or planned AWS environment can support governed operation
5. Priority-ranked risks and remediation actions - each linked to the regulation it engages
6. A clear next-step recommendation - proceed, remediate, narrow scope, or rethink

Possible outcomes

After the Assess phase, one of four things is true. Every engagement ends with a clear, bounded recommendation.

Proceed to landing zone and lighthouse

The service is coherent, the foundation is ready, and the first governed boundary is identified. Delivery begins with the landing zone.

Remediate the foundation first

The service may be sound, but the environment is not ready for governed deployment. Remediation is scoped and sequenced before delivery.

Rescope the service

The ambition is right, but the first deployment should be narrower. The assessment identifies which boundary to start with and what to defer.

Stop or rethink

The current design creates unresolved legal, safety, or governance failure modes that cannot be remediated within the proposed scope. This is not a failure of the assessment. It is the assessment doing its job.

MAP funding supports the Assess phase

For organisations migrating to or modernising on AWS, the Assess phase aligns with MAP Assess funding. MAP can offset a substantial portion of the engagement cost. But the reason to run the Assess phase is not funding. It is that governed healthcare on AWS requires a disciplined first step, and this is it. MAP makes it easier to fund the correct sequence.

Next steps and supporting frameworks

Start with a scoping call. We will tell you what the Assess phase covers for your boundaries, which tier fits, and what it produces.

Book a scoping call Score your boundary risk

Frequently Asked Questions

What do the six disciplines of the Inference Clinical Assess phase cover?

The six disciplines are: Service Design (whether the pathway and operating model can support governed operation), Legal and Regulatory (constitutional domains and lawful basis across boundaries), Clinical Safety (whether safety cases cover cross-boundary risk), Foundational Technology (whether the environment supports governed operation), Future Technology and Architecture (whether planned programmes create governance debt), and Boundary Governance (Seven Flows maturity and lighthouse candidates). Service design establishes whether the system is governable before legal, safety, and technical assessment begins.

How long does an Assess engagement take?

Duration depends on the tier. A Rapid Assessment covering a single material boundary takes 2 to 4 weeks. A Standard Assessment covering 5 to 8 boundaries takes 4 to 6 weeks and includes a co-design workshop. An Enterprise Assessment covering a full portfolio or PE-held group takes 10 to 16 weeks with multiple workshops and a sequenced programme.

Is the Assess phase eligible for AWS MAP funding?

What does the Assess phase produce?

The Assess phase produces a scoped view of the service and its boundaries, a first lighthouse candidate, a scored assessment across the six disciplines with priority-ranked findings, a landing zone readiness view, priority-ranked risks and remediation actions each linked to the regulation it engages, and a clear next-step recommendation: proceed, remediate, narrow scope, or rethink.

How does this differ from a standard IT audit or cloud readiness assessment?

Standard IT audits assess systems within organisational boundaries. The Inference Clinical Assess phase examines what happens between organisations - the boundaries where patients, data, and accountability cross. It covers six disciplines simultaneously because healthcare boundaries engage all of them. CQC inspects within organisations. DSPT assesses within organisations. Nobody measures the crossings between them.

How does service design evaluation fit into the Assess phase?

Service design evaluation comes first. Before we assess cloud readiness, we assess the service itself: what it does, where it crosses organisational boundaries, what responsibilities it creates, and whether the proposed operating model is actually governable. This produces a service boundary map, a first lighthouse candidate, and pathway risk framing. These become the governance design inputs for the Responsibility Ledger and Evidence Fabric.

What happens if the Assess phase recommends stopping or rescoping?

That is the assessment doing its job. Not every proposed service or migration is ready for governed deployment. The Assess phase may recommend narrowing scope to a single boundary, remediating the foundation before delivery, or rethinking a service design that creates unresolved governance failure modes. This protects the organisation from deploying into an environment that cannot support lawful operation.

Assess before you migrate, deploy, or scale.

What the Assess phase does

Engagement Tiers

When to use the Assess phase

The six disciplines

Service Design

Legal and Regulatory Review

DUAA 2025: Three provisions that change the Assess scope

Clinical Safety Review

Foundational Technology Review

Future Technology and Architecture Review

Boundary Governance Review (Seven Flows Assessment)

What you get

Possible outcomes

MAP funding supports the Assess phase

Next steps and supporting frameworks

Frequently Asked Questions