MSI's ISO 7101 Service Design Procedure Template

ISO 7101 Service Design Procedure Template and Guide

$169

A complete, editable ISO 7101:2023 Clause 8.7 service design procedure for healthcare organizations. Covers every element of the clause, plus the Clause 8.6 obligation to test, validate, and control artificial intelligence used in clinical decision making.

What is actually in the document

Clause 8.7 in full — all thirteen considerations from a) to m) — across sixteen numbered sections, three appendices and a healthcare process interaction map. Includes Clause 8.6 on emerging technologies, with the confirmations top management is required to make where artificial intelligence informs a clinical decision or a diagnosis.

  • 50pages, editable Word
  • 28obligations cross-referenced
  • 29MSI notes and callouts
  • 72marked decisions that are yours
Clause 8.7 a) asks for a document most healthcare organizations cannot produce. It requires the organization to define and document its process for designing or changing a service. Services change constantly — through a business case, a project group, a pilot and a start date — and nothing in that sequence looks like a design process. The decisions end up distributed across minutes, and nobody can show afterward that service users were engaged or that the risks were identified before the change rather than after it.

Three things service design rarely does

01 · Engage service users while options are still open

Healthcare organizations are good at asking service users about a service after it exists. Very few involve them while options are still being compared, because at that point there is nothing concrete to react to and the timetable is tight. But that is the only point at which their input can change anything. This procedure stages engagement before options are generated and again while they are compared, and records which option service users preferred — including where another was chosen, with the reasoning.

02 · Treat workforce wellbeing as a design input

Clause 8.7 j) places workforce wellbeing inside the design clause, next to patient safety. Most designs address it with a line saying no adverse effect on staff is expected, which is a conclusion with no working shown. This procedure asks what the design asks of people on a normal day and on a bad one, tests the establishment against the people who actually exist rather than the funded plan, and ends with the uncomfortable question: what in this design depends on goodwill?

03 · Decide that a pilot has become permanent

A pilot without an end date, success criteria and a decision point does not end — it becomes the service, without anyone having decided that it should, and without the design considerations ever having been applied. This procedure defines a go-live decision, and a pilot becomes permanent through it and no other way.

What’s included

  • The complete Clause 8.7 procedure — all thirteen considerations, sixteen numbered sections, editable Microsoft Word
  • A healthcare process interaction map, embedded and supplied as an editable SVG
  • A trigger list covering withdrawal, relocation and pilots, not only new services
  • Three project tiers, with withdrawals and anything changing who can access a service at the top tier
  • Multi-disciplinary team composition with authorities defined per project, and backfill identified as a resource under 8.7 c)
  • Service user engagement as a staged activity, with how participants were selected recorded
  • Risk identification that asks what a removed step was actually catching
  • Workforce and patient safety, and workforce wellbeing, as recorded design inputs
  • Access, outreach and equity — who can reach the service under the new design and who cannot
  • A testing step before go-live — pathway walked, failures table-topped, boundaries tested, and whether the service can actually be recorded in the time available
  • Clause 8.6 emerging technology and artificial intelligence, with five confirmations top management makes before go-live
  • A defined go-live decision, through which a pilot becomes permanent
  • A records table with no blanks, and a cross-reference covering every element of 8.7 and 8.6
  • Appendix A — Service Design Record in eleven parts, built as the go-live gate
  • Appendix B — Service Design and Change Log, with a pilot register
  • Appendix C — work instruction with a worked example: moving routine bloods out of a heart failure clinic

Every appendix, form, map and worked example is part of the document. Nothing is sold separately.

Who it’s for

Quality directors, patient safety leads, and transformation teams at hospitals, health systems, clinics and care providers implementing or certified to ISO 7101:2023. Also consultants supporting healthcare clients, where the absence of a defined service design process is a predictable finding.

Not sure yet? The free Design and Development Maturity Check scores eight elements in under five minutes, and your score appears without entering anything.

Questions

Why is it called service design rather than design and development?

Because that is the clause title. ISO 7101 Clause 8.7 is Service design in healthcare, and it is what healthcare organizations search for. The content is the design and development procedure for a service rather than a product.

Clause 8.7 is one clause. What is in the rest of the document?

Clause 8.7 has no separate sub-clauses for outputs, verification, validation, review or change control the way ISO 9001 and ISO 13485 do — everything sits in one clause with thirteen considerations. So the stage structure, the testing step and the go-live decision in this procedure are MSI method built on top of the clause, and they are marked as such throughout. That is stated plainly rather than blurred, and it is the reason the document is worth having.

Does it cover artificial intelligence?

Clause 8.6 requires that where artificial intelligence is used in healthcare decision making and diagnosis, top management ensure those processes are tested, validated and controlled. This procedure turns that into five recorded confirmations: tested on the population you actually serve rather than the vendor’s validation set, validated in the real clinical workflow with failure modes characterized, controlled with a named person able to withdraw it, explained to service users, and re-validated on a defined trigger.

Is this a template or a finished procedure?

Both, deliberately. It is written as a filled-in worked example so you can see what each element looks like when done properly, with bracketed placeholders wherever a value is genuinely yours to set — thresholds, roles, stage names, systems, retention periods. You are editing a working document rather than filling in a hollow outline.

What format is it?

Editable Microsoft Word (.docx), with the process interaction map embedded in the document and supplied separately as an editable SVG. Adapt it, rebrand it, and adopt it into your own document control system.

Will this pass an audit?

A procedure does not pass an audit; an organization does. What this gives you is a procedure that addresses every requirement of the clauses it covers, with a named owner and a named record, describing a process people can actually follow. Conformity is demonstrated by implementation and evidence. Unfilled placeholders are unmet requirements, so fill them.

We use different clause numbering.

Every cross-reference sits in a table at the back rather than baked into the body text, precisely so you can renumber without unpicking the procedure.

I already own MSI’s Design and Development course. Do I need this too?

The course teaches the method — how to get the process out of the heads of the people who do the work. This is the document. Where a form appears in both, this template carries the current revision; the version stamp in the footer tells you which you are holding. The template contains no video.

Can you help us implement it?

Yes. Call MSI at 760-434-9141 to schedule a planning session.