Notes for Mental health business architecture

Introducing . . .

Donna Kelly

twenty years business intelligence experience . . .

• Provided best practices in Data Warehouse Architecture to NHS National Programme in Leeds (NHS Spine/Secondary Uses Services)

• Created greenfield technical architecture for Acute Trust (WWL)

• Programme Manager and Enterprise Architect (combined business architect and technical architect) for greenfield Commissioning Support Service in support of 30 London Primary Care Trusts; brought organisation from empty offices to fully operational business intelligence status.

• Business Intelligence Programme Manager at Queen Elizabeth Hospital NHS Trust in King’s Lynn; created programme framework including infrastructure, organisation design and staffing, security , and methodology, in a total greenfield setting. Acted as Enterprise Architect, and created Theatre Business Intelligence for the Trust

• Consultant to Greater Manchester West Mental Health Trust, instrumental in moving the Trust to a strategic business intelligence framework. Provided both business and architectural consulting services.

• Interim Head of Quality, Performance and Business Intelligence for Vale of York Clinical Commissioning Group, managed relationship with York and Humber Commissioning Support Unit

• Interim Programme Manager for Cardiff University, performed review and reset of the programme, created new programme, provided architecture and methodology and brought home product delivery to the University. Role incorporated Enterprise Architect (combined business architect and technical architect).

http://www.redwing-bi.com

http://www.donnapkelly.com

[email protected]

0(781) 380-0181

1

Mental Health Trusts Business Architecture

© Redwing Business Intelligence 2002-2015

Mental health is the single most burdensome medical condition in the UK

It is also the Cinderella condition for funding and awareness

This sets the context to the Board for the business architecture


© Redwing Business Intelligence 2002-2015 2

Mental Health Boards (and organisations as a whole!) need an architectural framework for considering strategy and operational performance.

Boards should make a clear distinction between strategic and operational matters, focusing their attention on a limited number of key aspects of each.

The framework described here

• supports boards to make more efficient and effective use of information – and to spend more time on strategic matters

• structures the process of formulating strategy and shaping plans - and reviewing progress

• enables a balanced focus when scrutinising current and recent operational performance

Redwing believes this framework is flexible enough to:

• balance the crucial ingredients of success in financial, operational and quality terms

• cover the perspectives of patients, commissioners, clinical staff and managers, along with regulatory requirements

• allow organisations to select and modify those indicators that are most relevant to themselves in light of their own particular strategic priorities and/or trends and issues in their own performance

Crucially, Redwing believes that the architectural framework needs to be open, transparent, and comprehensible to the executives in charge of the enterperise.



There’s an associated document

Business Intelligence Technical Paper

Architecture: Origins

Redwing’s architecture has developed and evolved from days gone by, at DEC. The author was a Principal Consultant for Digital Equipment Corporation, and as a DART specialist, trained in Atlanta, Georgia, was very active in both developing and evolving architecture for DEC, and also in applying architectural solutions for DEC’s clients.

After DEC broke up in the 1990s, the author continued to evolve the architectural method; it has been an integral part of Redwing’s business intelligence offering for the last fifteen years.

It’s a layered architecture, and there are documents for each layer. The overall picture is in the slide.



Architecture is defined by business processes. The business process is centred around the patient.

There’s a matrix: the patient’s condition, and how the patient presents. For each of the points in the matric, there’s an integrated care pathway to be followed.

Each of these is a defined business process. This is the basis of the business architecture.

Every business process has events of interest. Data is recorded at the point of those events.

The important building blocks of the information systems architectural layer are also shown, for context.

This is how the loop is closed . . . From Board Vision, to patent-centric, to medical processes, to data recording, to data aggregation to create actionable information, which is fed back to the Board for Governance.



This is taken entirely from the Business Intelligence Jargon Buster,

http://www.slideshare.net/donnapkelly/business-intelligence-jargon-buster

This is a preliminary to a discussion of what’s in – and what is not in – scope for business architecture.

Key point here is that all Patient Journeys are functional processes – some Journeys have chunks of process in common, and some are unique to the specific Journey –but all can be analysed as a series of Events.

Process analysis by Event is the heart and soul of the business architecture.

When you know the things that can happen to the Patient, then you know the business.

Incidentally, it also generates the logical architecture of the data warehouse as a spin-off; Facts and their associated Dimensions define the data warehouse (using Kimball dimensional modelling)



These indicators could highlight inappropriate treatment, which could imply potential failures in partnership working.

For example, there should be no children in adult beds if there is adequate agreed partnership provision .

Importantly, these are PIs, and not KPIs.

The point is that every business process generates events of interest. Each event can be measured many ways . . . or, putting it another way, there are many, many performance indicators.

Which ones are key, however, and should therefore be reported on, is within the scope of a business intelligence delivery programme . . . and way out of scope for a business architecture.



Processes to be end-to-end defined – from the patient viewpoint

Not feasible to discuss - or even attempt to define – all processes here, but useful to look at one process as example. Discuss the slide. Then step back, and discuss the 5 generic points below.

First, define the goals of the process.

Second, ‘walk through’ the process identifying the events of interest.

Thirst, identify overlaps and white space.

Fourth, define simplified (or parallel processes - Champy BPR-style), together with high-level cost-benefit.

Fifth, provide the total information package to management for decision and possible action. There may be people in place already addressing this kind of thing.

NOTE: actual delivery of process improvement is way beyond the scope of business architecture expectations. It is included here for completeness. However, what iswithin expectations is the basics of identifying the process and its place within the total business architecture.



In the Architectural Overview (slide 5), there were two quite distinct information systems. One was Patient Administration, and the second was Business Intelligence.

The first is representative of all operational systems, which are the systems that support all of the day-to-day operational activities.

The second hoovers up masses of raw data from all these day-to-day transactional systems, and aggregates the data into actionable information (a.k.a. business intelligence).

Quality and Performance reporting is what comes out of the business intelligence system. Useful Quality and Performance reporting is information that the Board and management can use to guide their decision-making and actions.

It’s vital that the business architecture deliver this. Take a look at the example. All of the performance indicators need to be available . . .

. . . but do they need to be presented? In particular, do the green ones need to be present? (That’s actually within the scope of business intelligence delivery . . . not business architecture.)



It is necessary to record all incidents and to report them appropriately.

Each incident needs to be managed properly.

But then . . .

Whilst serious incidents are investigated in and of themselves – as a single incident –there’s also a need to look for patterns in the data.

For example, what about a war that has more falls, or pressure sores, than most? This could be an indicator that there’s no safety culture on that ward.

The board needs to see pictures, like floor plans, with heat maps.

The board needs to see trends – are things getting better or worse? One-off monthly numbers do not help.

This is critical to good governance.



Here are examples of proper information being given to the Board.

This is good governance.

These screen shots are taken from Redwing’s RAVEN service . . . Redwing is expert at provision of business intelligence regarding patient safety and safeguarding. We were the only SME to be invited to the National Patient Safety Congress last year, and we exhibited at the Congress 2014. We’ve been invited this year at the National Exhibition Centre. We also exhibited RAVEN at Patient First in London, and will be doing so again in November 2015.



These are the things that have to be done, in the order they have to be done.

I’m not going to read these out!

The slide is in the notes.



What should you expect to get at the conclusion of a business architecture exercise?

Here it is!



Here is one product that falls out from the business architecture.

It is the data warehouse design.

It is a drect result of the Process / Event analysis.

This particular component is part of the total data warehouse design. It is for Incident Analysis Intelligence. It provides the Board with actionable information to support good governance in this area.



Actions:

1. Understand the organisation

2. Review internal documentation

3. Identify key stakeholders

4. Meet key stakeholders

5. Identify current business systems

6. Identify organisational priorities – provision of information to ensure good governance, and to ensure patient safety.

7. Define the current business strategy, governance, and organisation

8. Define the key business processes, including the events.

9. Define the required future state

10. Identify the steps required to move to the future state

1. in terms that make sense to the business, and

2. which can be then implemented technically.





Notes for Mental health business architecture

Healthcare

theatre business intelligence

programme framework

architectural framework

mental health boards

new programme

nhs national programme

operational matters

trust consultant