Tag: Things

Posted on

What’s Wrong with UK Healthcare?

According to the June 2016 Britain Thinks survey (commissioned by the BMA), 37% were dissatisfied with the running of the NHS (up from 21% the year before) and 53% expected it to get worse.  In contrast, the 2014 report from US research foundation the Commonwealth Fund, found England’s NHS to be the world’s second cheapest major healthcare system while scoring top in six out of nine measures (effective care, safe care, coordinated care, patient centred care, cost related problems, efficiency). The report (Mirror, Mirror on the Wall) compared healthcare provision across eleven of the leading, western nations in a study of healthcare outcomes.  The NHS clearly isn’t failing but there’s no room for complacency.

Consider Leon’s experience when he was suffering from chest pains and shortness of breath.

MonitoringFirstly, Leon called NHS 111.  The call handling agent was unable to do much more than take details (1st explanation) and referred to a clinical colleague.  The out-of-hours clinician that called Leon back (booked by the 111 agent) carried out a triage covering the same ground (2nd explanation) as had been covered on the original call.  Concerned, the out-of-hours clinician referred Leon back to 111 who made a booking into an extended hours hub (a product of the 2015 GP Access Fund).  After a one hour wait, Leon was able to see a doctor at [coincidentally] his home practice.  The extended hours clinician did (it’s assumed) have access to Leon’s medical history but no access to the 111 details so Leon’s explanations had to be repeated (3rd explanation).  The extended hours clinician referred Leon to MIU for chest x-rays.  This referral was rather chaotic involving an instruction to go to the MIU connected to A&E and a printed encounter summary.  On Leon’s arrival at hospital, the nurse insisted on admittance to A&E (and not the MIU) but was not able to gain sufficient details from the encounter summary so Leon was forced to explain his condition again (4th explanation).  The x-ray was booked and a number of other tests (blood, ECG) carried out by rather harried staff in an ad-hoc fashion.  After a five hour episode of care, Leon was sent home with no clear diagnosis of what had happened but an assurance that he was OK.  Two hospital nurses, two GPs, one hospital doctor, an x-ray technician, one healthcare assistant (who took Leon’s blood) and the laboratory (who mislaid the test results for a time) combined across four care settings (111, out-of-hours, extended hours, hospital) to provide Leon’s care.

All-in-all, a rather disjointed experience with almost no sharing of data between the different care providers.  Assertions of the importance of Caldicott principles seem rather hollow when necessary data either isn’t exchanged at all or is printed out and manually handled.

So, what’s wrong with UK healthcare?

Leon’s experience (he was suspected of having a spontaneous pneumothorax) highlights a number of issues.  Firstly, those managing Leon’s encounters seemed to share almost no data, meaning that time was wasted with the situation having to be repeatedly explained (four times in Leon’s case).  Secondly, communication to Leon through the episode was limited, it was left to him to actively seek updates and clarify next steps.  Thirdly, the different care settings appeared as completely different organisations with call backs and re-registration rather than operating in concert to manage Leon’s situation as a single episode of care.

If we look across the world, Japan (not included in the Mirror, Mirror… report) spends more on healthcare, providing for a more elderly population but has a far lower rate of obesity.  Japan appears able to deliver significantly more provision at little additional cost but it is note-worthy that the level of obesity (a significant risk factor for type two diabetes) is very low by world standards.  This is relevant to UK healthcare where there were 2.7m people living with diabetes in 2013 and (according to the 2015 NHS England Annual Report) one in five primary school children are clinically obese.  If we add lifestyle demand (such as alcohol related hospital admissions) we must take the view that demand for healthcare is as important an element in solving the UK’s healthcare woes as is a reconfiguration of the way in which healthcare provision is organised.  Interestingly, “Mirror, Mirror on the Wall” placed the UK last in the Health Lives category.

Given a healthcare system that, by some objective measures, performs reasonably well; what can we do to address its pressing challenges?  Firstly, citizens (not just patients) need to be supported to manage their own social, mental and physical health.  We need to support people in living healthy lives and to intelligently seek out the right medical care when necessary.  Secondly, we need healthcare providers to work effectively together regardless of internal, organisational boundaries.  This needs patient information to be shared across care settings and for treatment to be organised across provider borders, driven by patient need.

References

Commonwealth Fund, Mirror, Mirror…

Posted on

Agile should mean Faster AND Better

If your digital project is late and its users are unhappy, it’s not agile.   Well, it could be tagged as agile by some (it’s got sprints, t-shirt sizing & stand-ups) but this is really rather pointless box ticking.  Today, resources need to be consumed purposefully and efficiently, and the drive for digital needs assured, “good enough” delivery.

I’m not suggesting that we throw out the agile baby with the tar-pit bath water here, most definitely not.  What I am saying is that we must shape our projects so that they deliver to order and, for digital, this covers faster.  Agile development is a valuable part of this faster, better delivery but there are some essential architectural underpinnings if we want success; fast, efficient, on time and on the money.

We (those tasked with facilitating change) need to understand what the enterprise wants to achieve and how.  More customers, more sales, more revenue per customer… they’re all good, we just need to know.  If there’s no documented strategy, objectives and KPIs can probably be found in the annual report but the “how” (critical success factors) may well not be expressed.  If you can engage chiefs or senior managers and find out how they want to achieve their objectives (I want to drive up customer numbers on the freebie service and then convert them to premium) this is great for building valuable relationships and strengthening buy-in.  I can imagine some of my agile colleagues developing hives at the thought of all the time wasted on this documentation but they’re wrong.  No engagement, no buy-in, no delivery; it’s that simple.  There’s a positive side to this too.  The resulting motivation model can be used to define scope (it doesn’t deliver a CSF or KPI so drop it) and priority (without this, that KPI can’t be measured so it’s a “Should”) so we’re lean.  It also helps to minimise change (we could change the user stories but it won’t improve support for that CSF) so we’re lean.

I’ve written before about the value of business object modelling (Things) to quality but it’s also great for speed & agility.  Things are easy to understand so they’re quick to attract buy-in.   Once we’ve defined them, we just need to build them.  The actions defined for each Thing are first-cut functions, the characteristics are first cut screens. A lot of time is typically wasted during iterative projects trying to nail these two sets of decisions and the result is often lots of screens/forms/pages that are variations on a theme, hence more work to do and a more complicated and more confusing user experience.  Definitely not lean.

The next tool in my cargo pants is a Capability model.  I’m a bit of a latecomer to this one but I’m finding these models really useful and tight.  We’re developing generic and sector capability models so we can provide a start for ten here.  Capabilities are easy to document, the technique is model driven (and uncomplicated) and they’re readily consumable.  Although process models are important downstream, the semantics and notations (even simplified BPMN) are an unnecessary complication at pre-project stage.  Capabilities are excellent for getting to a shared view of operations and models can be heat-mapped to give different perspectives.  Change is easily reflected and progress is rapid; so we’re agile.

The final tool in my small pocket is the Roadmap.  It’s great being bold and running off down a path but you can spend an awful lot of time running round in circles if you don’t know where you’re going.  Wasteful, not lean.  Many of you will have been on a project with a big elephant called Technical Debt slumbering in the corner.  You’ve made progress, there’s a beta to launch and everyone’s happy.  Who cares that it will fall over frequently and cost a fortune to strengthen.  It’s a beta, right?  I get the need for speed and agree there’s a need to hold back costs until we know there’s demand.  Roadmaps just mean that informed decisions can be made and the majority of technical debt avoided; so we’re lean.

Like “fail fast” and “good enough”, “slow start, fast finish” feels a little uncomfortable to begin with but it’s the right way to go.  So keep your user stories, burn-down charts and scrums; just add in motivation, things, capability and road-mapping if you really want to go digital.

Posted on

Building Spacious Systems…

Even though I sold it some years ago, I still reminisce about my old Kentish Town flat so what was great about it?  Well, firstly it was spacious.  Downstairs was completely open plan so given that I didn’t overfill it with furniture, there was a real feeling that you could definitely swing the proverbial…  Secondly, it was bathed in light as the back windows were wide, floor to ceiling affairs that opened the flat to the world (don’t worry, I had curtains).  The final great feature was not inside the flat but outside.  Access to my first and second floor “maisonette” was via a secure doorway, stairs (with a lift for the lazy) and a balcony/terrace which again opened the flat to the world as well as encouraging neighbourliness.  Once through the security gate and main door, things were fairly open and security wasn’t in your face.  I thought the developers were a bit rubbish so how did they build such a great place?

KTWhen building homes, for the majority of people, there are some fundamental principles.  Before we get to deciding between Smeg and Miele, creation of space (whatever the external constraints) and maximising natural light will always be desirable. Similarly, flexible, non-oppressive security will be another winner.  The same is true in building good technology; in parallel with reflecting specific requirements, there’s a set of principles to which almost all systems should adhere.  It should be easy to move around into areas that suit our inclination without constantly meeting obstructions.   We should also be able to benefit from natural illumination wherever we are… re-phrased, our way should be enlightened with knowledge as we go.  Finally, while security becomes ever critical as more of our lives are lived online, we don’t want that security to be so oppressive that our use of the technology is impaired.

I’d venture to say that if we applied just these three principles, our tech would be much, much better.  Easy navigation and having the right context (relevant information) can both be established by the adoption of a technique that I think is really, really strong.  Object modelling, user conceptual modelling and business entity modelling are all monikers for a technique that identifies, defines and then embeds the things with which we interact.  I’m not talking about normalised entities or implementation classes but the real things, be they physical or conceptual, that are all around us.  In a financial situation, I have an account that I use to purchase goods from particular merchants (Account,  Purchase Transaction,  Product, Merchant).  In a travel situation, I walk to my local station to catch a train that will take me to the shops (Station, Journey, Train Service, Location).

The beauty of these things, is that once identified, we can define them in a natural way and this definition can be shared with the technologists allowing them to implement equally naturally.  I’ve mentioned account, I’ve said that I want to be able to credit money to and debit money from my account; and I’ve called out the different characteristics of my account (balance, transaction history, facilities, regular debits, etc).  I’ve also said that I want to be alerted if there are any strange debits.  Given that I’ve gone to this trouble, I want it to be really obvious, when I’m using the technology, how I get to my account and really easy to access and do the things I’ve said.  So, as I’m making a purchase, for example, it would be really cool if I could see my balance after the transaction and what my overdraft limit is.

Behind the scenes, these things are used extensively.  As well as determining the structure of user interaction (accessible spaces, illumination), these things provide information definitions that can be normalised to generate data models and they outline the default set of services for our service architecture.  This is particularly helpful in agile development as we have a single model that can be used throughout our project without the need for repeated translation.  Translation is not a bad thing but the more translations we have, the more effort we expend and the more likely we are to make a mistake.

“… and what about security”, you ask.  Does Object Modelling help with creating unobtrusive security?  My location may not be a big secret but my changing locations over a period of time may well be personal and sensitive.  Therefore, in deciding how to control access to information, context is key.  Object Modelling supports the design of unobtrusive security by identifying the different contexts, the characteristics mentioned above.  If access to information is linked to these characteristics, access control can be simple and flexible.

Object Modelling can help us to build spacious systems with lots of light and flexible, unobtrusive security.  It’s a key technique in our approach to accelerating technology enabled change.