This is the case for every module Task (Modules 2–9). It is written as a request for proposal, so it also doubles as a worked example of the genre. The capstone uses a different customer; do not reuse the artefacts you produce here.
This organisation is invented. Any resemblance to a real business is coincidental. The numbers are chosen to make the arithmetic in Modules 3, 6, 7 and 9 work out, not to describe any real market.
Business context
Lumen Diagnostics operates a private diagnostic-imaging network: 180 imaging centres across four regions, working alongside roughly 600 independent partner radiology practices that take overflow and specialist studies.
Referrals arrive from clinics and physicians. Each referral must become an appointment at either a Lumen centre or a partner practice, matched on modality, urgency, patient location and price.
| Fact | Value |
|---|---|
| Studies performed per year | 4.2 million |
| Referrals received per day | ~14,000 |
| Imaging centres | 180, across 4 regions |
| Partner practices | ~600 |
| Current approach | Largely manual — phone and email between the referral desk, patients, centres and partner practices |
The manual process is the problem: it consumes referral-desk time, leaves partner capacity unused because nobody can see it, and produces no reliable utilisation data.
Project overview
Lumen wants to engage a Supplier to build a scheduling platform, delivered as a service and hosted and supported by the Supplier. It must become the single source of truth for imaging appointments, giving the referral desk, partner practices and patients a shared view of confirmed bookings.
Lumen is open to recommendations on system design to meet the objective. The Supplier should meet the requirements cost-efficiently.
Six aspects the system must account for — these are effectively the business drivers:
| Aspect | Requirement |
|---|---|
| Cost reduction | Centralised utilisation and financial reporting for day-to-day management and budgeting |
| Automation | Remove the existing manual scheduling and confirmation steps |
| Integration | Integrate with the existing referral management system, the patient identity service, and corporate single sign-on |
| Consistency | One coherent look, feel and process across every portal |
| Flexibility | A highly configurable solution that can support Lumen's growth |
| Performance | Sustain peak demand, and cope with disruption events such as a centre outage or a regional surge |
Functional requirements
Note as you read that several of these are written the way customers actually write them — loosely. Making them measurable is the Module 3 exercise.
| Area | Requirement |
|---|---|
| Availability search and prioritisation | Intelligent search across partner practice availability and manually uploaded slots, based on the referral's requirements. Prioritisation on clinical match plus custom rules set by the Scheduling Manager in the Administration Portal. Referral requirements originate in the referral management system and may be amended by the patient in the Patient Portal or by the Scheduling Manager. Prioritisation may change over time as rules change |
| Offer and confirmation workflow | Support the stages Requested → Triaged → Offered → Accepted/Declined → Confirmed → Completed → Billed, with email and SMS notification on stage change. Must allow the workflow to be changed and extended later. Alongside automated offers, support manual booking by the referral desk, capturing all details through web forms |
| Change management | Frequent synchronisation with the referral management system. New referrals, amendments and cancellations are driven by those updates. Conflicts merged according to a defined policy, with alerts to affected parties. Support manually reassigning a booking to a different centre or partner when required |
| Partner practice access | Partner practices access the system to manually upload available slots, pricing and capability details. Booking with these partners is handled manually |
| Automated partner integration | One partner group is integrated automatically through its scheduling API; all other partners are integrated manually. Preferred locations load initially from the referral system but may be amended in the Patient and Administration portals, with the ability to override them |
| Appointment consolidation | Support combining multiple studies for one patient into a single visit where clinically permitted |
| Patient Portal | View upcoming appointments with status and complete, accurate detail; confirm or decline an offered appointment; view and print confirmations; access via single sign-on; capture patient feedback and associate it with the appointment |
| Administration Portal | Lets the Scheduling Manager manage configuration, gives visibility of appointment status, and provides reporting — the front end for all administration of the system |
| Reporting | Support appointment detail, partner performance and financial reporting |
Non-functional requirements, as the customer wrote them
| Category | Requirement |
|---|---|
| Usability | Use current web technologies to deliver a clean, intuitive experience that helps users complete their task without friction |
| Usability | Work across a range of screen sizes, including phones and tablets, without degrading usability |
| Architectural | Provide a scalable, high-performing data platform capable of storing and querying large volumes of appointment and study data |
| Architectural | Keep the platform on currently supported technology versions, with periodic review of version suitability and planned upgrades |
| Architectural | Be configurable enough to absorb change in regulation, internal policy, clinical protocol or organisational structure without code changes |
| Availability and performance | Perform in line with modern expectations — routine screens should feel immediate, and large reports must not take so long as to frustrate users. Precise criteria to be agreed during design |
| Disaster recovery | Be highly available and resilient, minimising the risk of service interruption |
| Configuration management | Adopt adequate configuration management and version control across all environments and documents |
| Deployability | Employ robust procedures for promoting any change into the live environment, minimising disruption to operations |
| Scalability | Be designed so the solution can grow as the network expands |
| Data security | All authenticated traffic must use encrypted transport, TLS 1.3 or better |
| Data security | Handling and transmission of patient data must comply with applicable health-data protection regulation in each region of operation |
Read this list next to the Module 3 worked example and the whole exercise becomes visible. "Precise criteria to be agreed during design" is the customer declining to give you a number. "Current web technologies" is a constraint dressed as a usability requirement. And "configurable enough to absorb change in regulation, internal policy, clinical protocol or organisational structure" is a modifiability requirement that means nothing until somebody commits to how long a change may take — which is exactly what the worked example does when it holds the configuration team to one working day.
Growth assumptions you are expected to design for
These are stated separately because they drive the scalability and portability requirements rather than the functional ones:
- Lumen expects 12% annual growth in referral volume
- It intends to enter two further regions within three years, including one outside its current jurisdiction
- Patient-facing use is shifting to mobile — currently ~45% of patient portal sessions, and rising
- Partner practice numbers are expected to roughly double