May 2017 – tuhch

May 14, 2017May 14, 2017

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.

Monitoring Firstly, 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…

May 14, 2017May 14, 2017

Consultants & Architects

Having had an unplanned stay in hospital (I wouldn’t recommend pneumonia), I’ve been reflecting on the experience. Maybe I’m a bit strange but I can’t help but look at it through a consultancy lense; maybe interesting, maybe sad.

The paramedics were a bit like a sales team, always there when you call and full of reassuring words. Beneath the relationship management, there’s a real focus on qualifying out (you’re OK, you don’t need our help) or quickly getting you to hospital. The wards, with their skilled doctors and nurses, were like development teams, varied and core to delivery. From the intensity of acute care to the relatively sedate pace of a regular ward, patients perceive that it all happens in the wards. Finally, the consultants were like architects, focused on understanding the patient and determining what programme of treatment they really need. Their skill is getting behind the symptoms, understanding the underlying challenges and defining a course of treatment that will really work to bring about improvement.

After being deposited in casualty, consultants were the first medics that I saw. Initially, they directed the team on which examinations to conduct in order to figure out what was wrong with me and what interventions would best tackle my problems. Once things had calmed down, they spent more time talking to me, understanding how the treatments impacted and keeping me informed on what would happen.

During my time on the wards, the consultants were still overseeing my care. They would pop back, keeping me updated and making necessary adjustments to the plan.

Training The big surprise for me has been since leaving hospital. I’ve been handed over to a new consultant but she has full access to my details as well as the treatments established. There are tests planned to ensure that the treatment has worked but much of my time with the consultant has been focused on explaining what’s happened, reviewing progress to date and advising me on how best to assure short and long term recovery. The advice has been really useful; I know where I need to play it safe and where I should push to accelerate progress. Though the planned tests will be an objective assessment of success, I feel that I know what they’ll show because the consultant has alerted me to the signs and I’m alive to how I can manage things to get the outcomes that I want.

I wanted to thank about a hundred people for my care but the consultants stand out as shaping my treatment and really helping me to drive my recovery.

Now, back to architecture.

May 14, 2017May 14, 2017

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.

May 14, 2017May 14, 2017

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?

When 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.

May 14, 2017May 14, 2017

A History of Architecture

I’ve got to that age when one reflects on one’s career; the troubled projects, late nights, cancelled holidays, “go live” celebrations and [it’s work, honestly] client entertaining. Not quite rock-n-roll but a rich tapestry of consultancy and what strikes me, repeatedly, is how things change, but yet remain the same.

For my undergraduate thesis, I looked at three small businesses (we now call them SMEs), developing a picture of their business objectives, critical success factors and key performance indicators (motivation modelling) in order to understand what they wanted to be able to do (capability modelling) and what technology facilities (architecture building blocks) they needed. Since then, I’ve done analysis, development, management, selling (shh!) and lots of other stuff but I’m back doing architecture again. Like Viggo Mortensen’s character, I just can’t escape my past.

What we now call enterprise architecture was once an aspect of business analysis and before that was strategic planning. So if things really have remained the same, what can we learn from our architecture forebears? Our architecture is relatively young so let’s look at traditional architecture.

Physical architecture typically involves a professional team being commissioned by their client to plan, design and supervise the building of structures. The formative academic study of architecture in the UK (University College, 1841) shaped architecture as a fusion of art and science, I think this mostly holds for our architecture. We have clients (internal or external), we undertake commissions (contractual or not) and we plan, design & supervise. Do we, however, see art and science in our architecture? The importance of communicating ideas in a digestible and attractive way certainly needs artistic flare and the development of pleasant user experience needs artistic understanding and creativity. The need to understand people and their inter-relationships is critical to success so humanities come in to play, too. Maybe architects are the polymaths of the information world. To balance this accolade, maybe I should question whether we’re professional but let’s make that rhetorical.

One area of difference is the reach of architectural projects. Physical architecture is comfortably project based and, even when developing the head offices of corporate giants, has a specific area of impact. Our architecture, dealing with information rather than concrete and steel, has a much more enterprise impact and hence has an existence and mandate beyond the project. This is important as it does require an elevation for the practitioners of our architecture and it requires us to supervise for a longer period of time. Further, physical structures have a clear purpose (to get across the river safely, to comfortably house 1000 staff) so benefits realisation is clearer and sooner. As long as the bridge is inspected safe and cars can cross the river on it, the purpose has been achieved; Norman and Richard can be given a pat on the back and can cash their cheques. With our information structures, the basic achievement of purpose cannot be so clearly signed off and the full realisation of benefit may need a while to confirm. Our Zaha cannot be congratulated quite so readily.

Burj

Final, let’s consider context. Byzantine, Renaissance and other, older architectures are reflections of prevailing, cultural norms. Modern architectures can be said to be establishing styles and setting trends that other aspects of society later adopt; notable in this regard is Bauhaus. Corporately, the move from evolved to architected enterprises (though early stage) emulates this lifecycle of physical architecture.

So…

Architecture needs a wide variety of skills; arts, humanities & science
Architecture is about change so buying in architecture is completely valid
Information architecture does not have physical form on which rules of certainty can be employed so we must accept a degree of ambiguity
The change from evolved to architected happened in the physical world and is rightly happening in the digital world

Our history is indeed shadowing that of our cousins in physical architecture; things do remain the same.