Tag Archives: requirements

Initial Mental Health Requirements

Torbay Hospital In-patient wards and ...

Torbay Hospital In-patient wards and treatment centres for mental health patients on the west side of the complex. (Photo credit: Wikipedia)

The previous couple of posts in this category haven’t exactly been exciting but they are important for context. Now things can concentrate more on the solution we are going to create.

There are two main classes of business intelligence required – clinical and operational. The most important user stories are listed in italic text below.

Clinical Requirements

Clinicians want to know how effective treatments are; patient outcomes; diagnosis statistics and critical incident analysis:

As a doctor I want to see treatment counts by patient and outcome so that I can determine the most effective treatments.

As a doctor I want to see critical incident counts by patient and mental health professional.

Operational Requirements

Operational business intelligence is primarily concerned with service costs, efficiency and capacity planning:

As an operational manager I want to see counts of assessments, treatments and discharges so I can plan capacity and monitor the number of patients in the system.

As an operational manager I want monitor prescribing costs to budget effectively and look for unusual prescribing patterns.

As an operational manager I want to see the number of bed days available and used so that I can monitor capacity and make sure suitable out of area options are available if needed.

As an operational manager I want to see complaints by patient and mental health professional so I can make sure the service has a good customer focus.

Other Requirements

Finally, there are also IT requirements which must be satisfied but since they are not value-add for patients and doctors I’ll look into them later.

This list is not exhaustive but the plan is to be agile – list the most important requirements, stack rank them and work down the list in iterations and re-plan often. Requirements will change, new ones will become apparent and some may even disappear before implementation starts. We will embrace this and not worry about the future too much.

Customers don’t care about requirements

They only seem to care because we, as software developers, make them play the requirements game. In reality, the only thing that matters is how the product matches up to their expectations. The big problem is that you can’t capture them in a document to use as the blueprint for development. There are some things you can to make sure your customer is happy with the result:

  1. Write a short “Vision” document describing the key features to get everyone on the same page early on
  2. Program by feature to produce functionality early, don’t spend too much time on infrastructure
  3. When you’ve completed a feature, show it to the customer and get feedback
  4. Allow the customer to change their minds

These points will only work when both you and the customer share the project risk; either with fixed rates/variable time or fixed time/variable functionality.

If it’s a fixed price/fixed functionality contract then you’d better start writing those requirements…