Skip to main content

Example: a systems-consolidation mission

This is a complete, filled-in mission for a different shape of programme than the everyday-application example — replacing a fragmented estate of legacy systems rather than building something new. It follows the same eight-section guideline, and was written to demonstrate a mission that scores well against all six mission-analysis checks: stated numbers paired with stated edge behaviour, named stakeholder classes, and explicit success criteria throughout.

See Writing mission statements that pass analysis for the reasoning behind specific choices below. Kilbrennan Regional Health Group is fictional; this is not written for or about any real organisation.

Mission Statement — Kilbrennan Regional Health Group Systems Consolidation

1. Business Purpose​

Kilbrennan Regional Health Group (KRHG) operates four hospital sites and eleven community clinics. Over three decades of local procurement, service mergers, and acquisitions, the Group has accumulated 20 separate clinical and administrative systems, named individually in Section 2 — patient administration, theatre and outpatient scheduling, laboratory and radiology reporting, pharmacy dispensing, maternity, emergency department tracking, bed management, referral management, HR and rostering, payroll, procurement and inventory, finance, incident reporting, occupational health, and a shared-care feed (the interoperability link that sends encounter and result data to community GP practices) — none of which share a common patient identifier or a common data model.

This programme exists to replace that fragmented estate with a smaller number of properly integrated systems, built from requirements that are traceable to a real clinical or operational need — a named safety incident, an audit finding, or a stated cost driver — rather than to whatever the previous system happened to do. The immediate driver is patient safety: staff currently re-key the same patient details into an average of four systems per admission, and two serious incidents in the past eighteen months have been traced to a patient being matched to the wrong record across systems that could not tell they were looking at the same person. The secondary driver is cost: KRHG pays 20 separate licensing, hosting, and support contracts for systems whose functions overlap enough that at least six of them duplicate patient demographic data entry with no reconciliation between them.

Success is measured on two things, not on delivery speed: the two-incident annual rate for cross-system patient-matching errors falling to zero, and licensing plus support spend across the replacement estate falling below the current combined spend on the systems it replaces, measured 12 months after each phase's go-live.

The programme is explicitly not responsible for delivering the replacement systems themselves. Its output is a validated, traceable requirement set — organised so that procurement, in-house build, and configuration of a commercial platform are all viable routes to satisfying it. It does not select a vendor, does not commit to a big-bang cutover over a phased one, and does not make clinical practice decisions; those remain with the Clinical Reference Group (the body of nominated clinical leads described in Section 3) and the Programme Board (KRHG's programme governance body, described in Section 3).

2. Business Scope​

In Scope​

  • A single, authoritative model of "patient", "encounter", "clinician", and "location" that every replacement system must conform to.
  • Requirements for patient administration, scheduling (theatre, outpatient, and diagnostic), laboratory and radiology result reporting, pharmacy and e-prescribing, bed management, and the shared-care feed to community GP practices — the systems directly implicated in the two safety incidents.
  • Requirements for the data migration and record-matching approach needed to retire the current systems without losing clinical history.
  • A regulatory and interoperability baseline (data protection, clinical safety, and interoperability standards) that every requirement is checked against.
  • Requirements for staff training and change management needed to adopt the replacement systems safely.

Out of Scope​

  • HR, payroll, procurement, and finance systems. These are lower clinical-risk and are being addressed by a separate Corporate Systems programme on a later timeline; this mission's requirement set may reference them at integration points but does not define their replacement.
  • Selection of a specific vendor, platform, or build-vs-buy decision — this programme produces the requirement set that decision will be evaluated against.
  • Physical estate, medical equipment procurement, and clinical protocol changes not driven by system replacement.
  • Emergency Department tracking is reserved for a second phase once the phase one systems are stable; it is out of scope for this requirement set.

Envelope​

The requirement set is used by KRHG's Digital Programme team, by whichever supplier or in-house team ultimately builds against it, and by the Clinical Safety Officer for sign-off. The 20 named legacy systems making up today's estate — listed here for context, not all of them in scope for this requirement set; see the In Scope/Out of Scope split above — are: patient administration, theatre scheduling, outpatient scheduling, diagnostic scheduling, laboratory information, radiology information (PACS), pharmacy dispensing, e-prescribing, maternity, emergency department tracking, bed management, referral management, the shared-care feed, HR, payroll, rostering, procurement, inventory, finance/billing, and incident reporting — spanning 4 hospital sites and 11 community clinics, serving roughly 3,400 clinical and administrative staff and approximately 210,000 registered patients.

Expected data volumes are 40,000 inpatient admissions and 260,000 outpatient attendances per year; the replacement systems must handle volumes up to 25% above these figures while keeping the 95th-percentile interactive response time within the 3-second target set in Section 7, and sustained volumes beyond that trigger a capacity review rather than being treated as a silent failure mode. The requirement set must remain valid whether the eventual solution is delivered as a single integrated platform or as several systems joined by an integration layer — it is deliberately written to be solution-neutral.

This requirements programme is expected to take 9 months to full sign-off across all in-scope services (see Section 7); full site rollout of the resulting build is expected to take a further 30 months after that, with a phased go-live by clinical service rather than a single cutover date — a total programme span of approximately 39 months from today to the last service's go-live. See Section 7 for what happens if either the 9-month or the 30-month figure is at risk.

3. Stakeholders and User Classes​

Stakeholders and what they need

  • KRHG Chief Executive and Board — own the outcome and the safety case; need assurance that patient-matching risk is closed and that cost is reduced against current licensing spend.
  • Clinical Safety Officer — owns clinical risk sign-off under the clinical risk management framework named in Section 8; needs every requirement's patient-safety implication assessed before build begins.
  • Chief Clinical Information Officer — owns clinical usability and workflow fit; needs requirements expressed in terms clinicians recognise, not system jargon inherited from the legacy estate.
  • Data Protection Officer — approves lawful basis, retention, and cross-system data sharing; needs a single view of what personal and special category data moves where.
  • Programme Board — KRHG's programme governance body; owns scope, budget, and the phased delivery plan; needs traceability from requirement to the safety incident or cost driver that justified it.
  • Clinical Reference Group — the body of clinical leads nominated one per in-scope service (see Section 6); confirms requirements reflect real clinical workflow before a service's requirement set is signed off.
  • Community GP practices (external stakeholders, not KRHG staff) — depend on the shared-care feed; need continuity of the data they currently receive during and after migration.
  • National health data standards body — approves the interoperability profile KRHG commits to; needs conformance evidence at each phase.

User classes (software-interacting)

  • Ward and clinic administrative staff — daily, heavy use. Register patients, manage appointments, update encounter records. Currently the group most affected by re-keying across systems; lowest tolerance for added clicks per task.
  • Clinicians (doctors, nurses, allied health professionals) — daily use during clinical care. Read and record clinical observations, order and review lab and radiology results, prescribe. Need a single patient view across the systems in scope; currently switch between three to five systems per patient encounter.
  • Laboratory and radiology staff — daily use. Receive orders, record results, flag critical values. Need order-to-result traceability that survives a patient being seen at a different site than the one that placed the order.
  • Pharmacy staff — daily use. Dispense against prescriptions, check interactions. Need real-time visibility of a patient's current medication list, which today exists in at least two systems that do not reconcile automatically.
  • Bed managers — daily use, several times per shift. Need real-time occupancy and expected-discharge data currently maintained by phone call and spreadsheet between four sites.
  • Community GP administrative staff (external). Occasional use, several times per week. Consume the shared-care feed; do not have write access to KRHG systems.
  • Digital Programme and supplier delivery staff. Intensive use during build and migration; need full audit and configuration access, withdrawn at go-live.
  • Clinical Safety Officer and Data Protection Officer. Periodic, high-consequence use: review requirement sets and migration plans for sign-off before each phase proceeds.

4. Operational Concept​

The programme separates three kinds of work, and keeping them separate is the point of this mission. Deterministic data-quality rules — the patient-matching rule set — define what a valid patient match, a valid encounter, and a valid result look like; these rules are authored once and apply across every system in scope. Requirements analysis (this programme's actual output) turns clinical and operational need into a traceable, testable requirement set. Delivery — build, configuration, or procurement — is the responsibility of whichever team or supplier is selected once the requirement set is signed off; the Programme's involvement in a service ends at handover, marked by a signed acceptance of the requirement set from the receiving delivery team and the Clinical Safety Officer.

In normal operation, requirements analysis proceeds service by service rather than system by system: for example, "outpatient attendance" is analysed as a single clinical workflow that currently touches four legacy systems (patient administration, outpatient scheduling, the shared-care feed, and — for a subset of clinics — a spreadsheet-based waiting list), and the resulting requirements describe the workflow KRHG needs, not a replacement for each existing system in turn. Every requirement is checked against the patient data model (Section 2) and the clinical safety framework (Section 8) before it is accepted into the set. Named safety incidents and audit findings are tracked back to specific requirements so the Clinical Safety Officer can confirm each identified risk has a requirement that closes it, not merely a requirement that is thematically related to it.

5. Scenarios​

Routine — outpatient attendance. A patient attends a follow-up outpatient appointment. The clinician opens a single patient view showing demographics, current medication, and the most recent relevant lab result, regardless of which site each was recorded at. The appointment outcome is recorded once and is visible to the patient's GP practice within the shared-care feed's 15-minute refresh window (see Section 7), without manual re-entry.

Patient-matching near-miss. Two patients with the same name and similar dates of birth are registered on the same day at different sites. The patient-matching rule set flags the ambiguity before either record is used clinically, presents the discrepancy to registration staff with the distinguishing details needed to resolve it, and does not allow either record to be merged automatically.

Critical lab result. A laboratory result flagged as critical is authorised. The ordering clinician, and a named cover clinician if the ordering clinician is off duty, receive notification within 15 minutes; an unacknowledged critical result escalates to the site's on-call clinical lead within 30 minutes of the original notification.

System degraded — integration layer unavailable. The integration layer connecting two of the replacement systems becomes unavailable. Each system continues to function using its own local data; a clear indicator shows staff that the shared view may be out of date; queued updates apply automatically once the layer recovers, and nothing is silently lost or silently duplicated.

Migration cutover for a single service. Outpatient scheduling for one hospital site migrates to the new system while the other three sites remain on the legacy system. Patients and staff at the migrated site see no change in the appointments already booked; the shared-care feed to GP practices continues without interruption for all four sites throughout the transition.

Data subject access request. A patient requests a copy of the personal data KRHG holds on them. Because the patient data model (Section 2) is shared across the replacement systems, a single query against that shared model returns every system's holdings for that patient, within the timescale required under data protection law, rather than requiring a separate request to each system's administrator.

6. Assumptions​

  • The Individual Health Identifier (IHI), issued under Ireland's Health Identifiers Act 2014, is available to every replacement system and is treated as authoritative for patient matching; the requirement set does not invent its own identifier scheme. Where a legacy system's records predate IHI allocation, matching those records to an IHI is itself a migration requirement, not an assumption resolved in advance.
  • The Clinical Reference Group will nominate one clinical safety lead per in-scope service (outpatients, laboratory, pharmacy, bed management, and so on) before requirements analysis for that service begins; if a service has no nominated lead by that point, requirements analysis for that service is paused rather than proceeding on assumption.
  • Community GP practices continue to consume the shared-care feed in its current interoperability format for the duration of the migration; a change to that format is a dependency this programme must raise to the Programme Board, not decide unilaterally.
  • Sign-off of a service's requirement set means every HIGH-severity finding from its mission and requirement analysis is resolved and every MEDIUM finding has a recorded disposition; a service is not treated as signed off on a lower bar than this. The 30-month programme duration (Section 2) assumes each service reaches that bar before its build begins.
  • Legacy system vendors will provide a full export of structured patient data, in a format the migration tooling can read without manual transformation, for each system being retired. Two of the twenty systems have no active support contract; for those two, this assumption does not hold, and a data-recovery risk is raised for them rather than assumed resolved.
  • Funding for the replacement systems themselves (as distinct from this requirements programme) is a Programme Board decision outside this mission's control. The Programme Board commits to approving or declining funding for a service's build within four weeks of that service's requirements sign-off; if four weeks pass without a decision, the delay is raised to the KRHG Board as a schedule risk rather than left unresolved.

7. Constraints​

Operational

  • Interactive transactions (patient lookup, appointment booking, result review) complete within 3 seconds under normal load, measured at the 95th percentile; this is the target referenced in Section 2's capacity constraint.
  • Clinical staff availability for requirements workshops is limited to two hours per week per nominated clinical lead. If two hours proves insufficient for a service's requirements analysis, the nominated lead's service manager is asked to approve additional time before that service is descoped on availability grounds alone.
  • No requirement may depend on a change to headcount; the replacement systems must be usable by the current staffing establishment.
  • The shared-care feed to community GP practices must not be interrupted for more than 4 hours at any point during migration. An interruption approaching 4 hours triggers an automatic rollback of the migration step in progress; GP practices are notified through the postal/fax fallback channel already in place for feed outages, not left to discover the gap themselves.
  • The shared-care feed refreshes at least every 15 minutes during operating hours; this is the "refresh window" referred to in Section 5.

Commercial and organisational

  • The requirements programme itself operates to a fixed budget of €480,000 and a 9-month timeline to full sign-off across all in-scope services. Spend and schedule burn-rate are reviewed monthly by the Programme Board; a service at risk of exceeding its share of budget or timeline is descoped proactively at that review, not only once the budget is fully spent.
  • If the 9-month timeline is exceeded for a service already under analysis when the budget is exhausted, that service's analysis is suspended at its current state and resumed only if the Programme Board approves further funding; it is not carried forward silently.
  • A phase that would exceed the 30-month delivery envelope (Section 2) is extended only with Programme Board approval; services already live in an earlier phase are not paused as a consequence of a later phase's delay.
  • KRHG's data protection and clinical governance policies take precedence over any efficiency gain a requirement might otherwise justify.
  • The requirement set must remain vendor-neutral — naming no specific supplier or commercial product — so it can be used in either a competitive procurement or an in-house build without rework. Mandating conformance to an open interoperability standard such as HL7 FHIR (Technical constraints, below) does not conflict with this: the standard is not itself a vendor, and requiring it keeps every vendor's system interoperable rather than favouring one.

Technical

  • Every replacement system must conform to the national health data interoperability profile (HL7 FHIR-based) for any data it exchanges with another system in scope or with the community shared-care feed.
  • Personal and special category health data must be handled in line with applicable data protection law and with information security management aligned to ISO/IEC 27799 (health informatics security management) and ISO/IEC 27001.
  • Every requirement affecting clinical workflow must be assessed for clinical risk under the clinical risk management framework named in Section 8 before it is accepted into the signed-off set; a requirement with an unclosed clinical risk cannot proceed to build.
  • User-facing interfaces must meet WCAG 2.2 AA accessibility conformance, evidenced by assistive-technology testing before go-live for each service; this testing is budgeted within each service's own requirements-analysis allocation, not treated as a late addition.
  • The patient-matching rule set (Section 4) must achieve a false-match rate no greater than 1 in 100,000 comparisons in testing before any service goes live. A service that does not meet this rate does not go live on its original design: its matching approach is re-engineered and re-tested against the same threshold, and the service's go-live date moves to whichever later phase the re-test can be completed within. Once live, the rate is monitored continuously; three or more confirmed false matches in any rolling 90-day period triggers the same re-engineering and re-test process, and the Programme Board reviews whether the service should continue operating while that work is done.

8. References and Applicable Standards​

  • Applicable EU and Irish data protection law (GDPR and the Data Protection Act 2018) — lawful basis, consent, retention, and data subject rights for personal and special category health data.
  • HL7 FHIR — the interoperability standard the national data interoperability profile is based on; governs how replacement systems and the shared-care feed exchange data.
  • ISO/IEC 27799 (Health informatics — Information security management) and ISO/IEC 27001 — information security baseline for systems handling patient data.
  • Clinical risk management framework — KRHG's Clinical Safety Officer requires every clinical-workflow requirement to pass a clinical risk assessment; the specific national or international standard KRHG will formally adopt (a DCB0129/0160-style framework is the leading candidate) is a Programme Board decision not yet confirmed, and is tracked as an open item against Section 6's assumptions rather than presented as settled.
  • WCAG 2.2 AA — accessibility conformance target for all user-facing interfaces.
  • Health Identifiers Act 2014 — the legislation establishing the Individual Health Identifier (IHI), the patient identifier every replacement system's matching must be authoritative against (Section 6).