Tag Archives: mental-health-project

Mental Health Referrals – First Feature Acceptance Test

Leave a reply

I’ve been working on this for a few weeks now, half an hour at a time in the evenings and I can safely say it’s pretty hard to maintain a train of thought in thirty minute intervals. However a bare minimum implementation is complete and ready to discuss.

We start with an acceptance test:


Feature: Referrals Count
As an operational manager
I want to see counts of referrals
So I can plan capacity and monitor the number of patients in the system
Scenario: Simple Referral
Given the following referrals:
| Patient | Referral Date |
| Jane Smith | 2013–01–01 |
| Robert Jones | 2013–01–02 |
| Jenny Lee | 2013–01–03 |
When I load the referrals
Then the referral count should be 3
And the referral count for 2013-01-01 should be 1

view raw

ReferralsCount.feature

hosted with ❤ by GitHub

The first part of the feature describes the user story and the second part tells us that when we load three patient referrals then the total count should be 3 with 1 on the 1st January.

I’m using SpecFlow for acceptance tests since it is very easy to define tables and there are some useful binding utilities as we will see. After entering the test we can immediately compile the application and run the tests without writing anything else. The test will obviously fail since we haven’t written any code. In fact the acceptance test will stay broken for some time as we write code and unit tests. When it passes we know the feature is done.

So thinking about this functionally we effectively want to write a function that transforms an enumerable of source referral records into an enumerable of referral facts; then pipe this iterator into a SqlBulkCopy instance. Effectively this code needs to work:

referralrepository.BulkCopy(referrals.Select(x => mapper.Map(x)));

This is a Linq transform with a mapping function applied to each item in the source list. In the next few posts I’m going to break it into bite size chunks to implement.

Mental Health Dimensional Model

Leave a reply

For this week’s post I want to continue the sample solution. Even though I’m going to be as agile as possible we still need to have a rough idea of a roadmap and the best way to do that is with a dimensional model.

Each business process we want to model is represented as a fact on columns. They are all to be stored at the transactional grain except possibly admissions. The conformed dimensions are listed on rows with the facts they are related to.

Referral Assessment Treatment Discharge Complaint Incident Admission
Date

•

•

•

•

•

•

•

Diagnosis

•

•

Health Professional

•

•

•

•

•

Patient

•

•

•

•

•

•

•

Referrer

•

Service (Tier)

•

•

•

•

Time

•

•

•

•

•

Treatment Outcome

•

Clinic

•

•

•

•

It is interesting to note that this is a very patient focused model since that dimension is related to every fact. There are some unanswered questions within the model though:

  • How do we represent treatment outcomes? Is there a standard method? Can this be represented in a single dimension?
  • What grain are admissions? Given the goal of calculating ‘bed days‘ we might need to model them as events in progress.

I think we have enough to make a start and I don’t think we will deliver faster if we stop to resolve these issues first. Initially I’m going to concentrate on referrals, assessments and discharges since the number of patients in the system is one of the most useful metrics to monitor.

Initial Mental Health Requirements

Leave a reply
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.

Classes of stakeholder

Leave a reply

bournemouthlibrarySo this is the second attempt at writing this post. The first was very complete but read like a textbook and it makes more sense to read a real book – I recommend the stakeholder section in this book: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives.

All stakeholders have requirements, needs and interests which collectively I call “concerns”. I even track them in the same work item tracking system used for requirements since it means they never get lost and you can ensure traceability from concerns to requirements and architectural decisions.

The classes can be broadly split into three groups. The first being “receivers”:

  • Acquirers
  • Assessors
  • Users
  • Administrators
  • Support staff

Acquirers may be wanting your software for a number of reasons. They might not actually use it so their concerns are likely to be related to cost, need and satisfying other concerns indirectly, for example purchasing reporting software because a regulator has demanded accurate reporting of patient outcomes with possible penalties for failure.

In the mental health arena there are many additional “assessor” agencies and regulators such as the Care Quality Commission, Monitor, professional bodies such as the General Medical Council and watchdogs like Healthwatch. Fortunately they are mainly concerned with the quality of healthcare, patient outcomes and overall costs; less so about software.

Administrators and support staff want to spend as little time, money and effort as possible with your solution so anything that eases deployment, automatically heals or diagnoses issues and keeps the software running will help. Its worth looking further though – what if an administrator has a review objective of reducing disk costs over the year and you turn up asking for terabytes of clustered storage?

The second group of stakeholders are the “producers”:

  • Developers
  • Testers
  • Maintainers
  • Suppliers

Their concerns should be easy to list and meet since they want the same things as you. In this sample project the only producer is me and anyone who supplies me with coffee.

The remaining category are “communicators”. The book defines them as those who “…explain the system to other stakeholders…” but I think is should also include anyone who will discuss, promote, detract, educate, deny, network, rally and gossip about your project and are not in either of the other two groups. They may only by interested in your project for their own political reasons.

Do you have stakeholders from all these categories? If so look at things from each stakeholder’s angle and try to imagine what their needs are. Then go talk to them and confirm it.

Mental health stakeholder analysis – power and interest

Leave a reply

So its great that we know a little about how mental health services work but as an architect we need to cover some more ground before the project can be considered up and running. This post is about the slightly dirty subject of stakeholders and politics.

Why do this? Well getting the politics right can mean the difference between a success and failure. All projects have stakeholders with specific concerns. Some can be ignored but in general it is the architect’s job satisfy those concerns. Some stakeholders  have more power than others; they will also have varying levels of interest. The diagram below shows the best approach for each of the categories.

  • StakeholderEngagement Low Interest – Low Power: the easiest category to deal with since they are not too concerned with the project and don’t have the ability to derail you. Just monitor them for feedback  and other  information.
  • High Interest – Low Power: this class of stakeholders want to know what is happening and still don’t have the ability to disrupt the project. The best tactic is to ensure they are well informed.
  • Low Interest – High Power: these stakeholders can be the most difficult to deal with since they have the power to influence not only your project but many of the other stakeholders. The main issue being that they are not that interested so it is difficult to have meaningful discussions and  negotiations. The primary tactic is to ensure their concerns are met with as little fuss as possible.
  • High Interest – High Power: not only do they have the power to effect change but are interested in the outcomes. Personally I find this group a lot of fun since they can contribute to some very interactive sessions. The best tactic is to engage them which shouldn’t be too difficult given their level of interest.

In the next post I’ll cover classes of stakeholder and why it some of the non-obvious ones might be the most important.

Mental Healthcare Workflow

1 Reply

As I mentioned in my last post I wanted to setup the scenario I’m going to use for my examples. My lovely wife is a child psychiatrist so I have learned a fair amount about the way psychiatric services work in the UK. Lets dive right in.

There are four main workflow steps to all patient care:

  1. Referral – prospective patients are referred to the service with behaviours that indicate a mental health problem.
  2. Assessment – a file is opened for the patient and they are assessed. If required, tests are performed, then where appropriate a diagnosis is given and the patient is referred for treatment or discharged.
  3. Treatment – depending on the diagnosis, one or more treatment approaches may be required. Each approach has a outcome: either further assessment and treatment or discharge.
  4. Discharge – the patient is released from mental health services.

There are two queues in the workflow:

  1. Assessment queue – those that have been referred but are waiting assessment. There is a government target of 4 weeks for this queue.
  2. Treatment queue – those that have a diagnosis requiring treatment. There is a desirable target of 6 weeks for this queue for the patient to begin their first treatment.

Some additional notes:

  • Whilst a patient may be seen by many professionals during treatment there is usually a single mental health professional that oversees the overall care.
  • There are multiple levels of discharge – each treatment approach and then final discharge from the service by the lead professional.
  • Diagnoses in the UK are made according to the International Classification of Diseases (WHO) which covers all diseases and includes mental health disorders. Other countries such as the USA diagnose using the Diagnostic and Statistical Manual of Mental Disorders.
  • Services are divided into tiers from Tier 1 (GP treatment) to Tier 4 (intensive, possibly in-patient, treatment).
  • There are other business processes that don’t contribute directly to the value stream but are essential to the overall efficiency of the service and quality of patient care such as treatment reviews.
  • Treatments are conducted over a number of sessions. Even if the treatment is medication there are still sessions required to monitor and evaluate the drug effects and side-effects.

I’m sure this isn’t a complete picture but its enough to make a start. First we need to look at some requirements; then review the stakeholders and begin to outline the architecture.