The Journal of mHealth Vol 2 issue 5 (Oct) | Page 6

How to Build Clinically Effective Health Systems

How to Build Clinically
Effective Health
Systems

By Dr Alexander Graham

Dr Alex Graham is a medical doctor by background, having trained in London before entering the
business world. He is currently a founding partner at AbedGraham, a research and strategy consultancy which assists global IT corporates to navigate the clinical, organisational and commercial complexities
of the UK’s National Health Service (NHS). He is also medical director of EMEA for Imprivata.
The adoption of digital healthcare systems is the most important but also the
most difficult part of healthcare technology. When we consider building technology into health systems, the issues are
usually people related rather than software or hardware related. Everyone in
the transaction process be they the board
members or IT team at the hospital, the
sales people from the IT vendor or the
clinical frontline staff, will have their own
agendas, markers of success and personal
risk associated with the project. The risk
is always that one stakeholder within the
system misses out and the notional benefits for them soon become hindrances.
I believe we are not learning the lessons of old when it comes to healthcare
technology. There are too many projects
which overrun in time and cost, don’t
provide the appropriate clinical support
and lead to further dissatisfaction with
health IT. Below are a few markers I like
to use when it comes to the clinical staff
in the adoption process, although these
tips could quite easily be used for other
stakeholders as well.

4

Clinical agendas
Every single clinician will have a different
set of success markers with any IT project. But these are not limited to doctors
vs. nurses vs. physios etc. The workflow,
patient contact points and IT usage varies
hugely between individual departments
and even grade. A first year A&E doctor
will use IT far differently from either an
A&E consultant or a first year ward doctor. The issue with building large ecosystems or transformation projects is that
you must appreciate the variation in agendas in the clinical workforce. You have to
spend time getting to know what people
actually do on a day-to-day basis

October 2015

before you start implementing something
that is going to alter the way they work.

of a huge number of them before they tell
you. Never assume, always ask.

Language
One key issue when you bring together
disparate group is that aside from agendas, everyone has different competencies
which manifest themselves in the language
they use. Medicine is a world within itself,
and being involved in the medical sphere
involves the accumulation of essentially a
new language, and the same will be true,
to a degree, for IT staff, vendor employees and so on. As a result of this, communication and understanding of each
other becomes a real challenge, especially
as it takes up to 6 years to become a doctor. The only real way to get around this
is to have clinical support and interaction
at every level, including the vendor, such
that a common idea of the clinical issues
and solutions can be generated.

Use them during
The initial launch stage is the best time for
system failure and disenchantment. This
is the stage that is most likely to generate
patient safety and data issues and negative
brand connotations. When building anything complex or multifactorial in health
IT, it’s essential to have a rigorous handholding process from both the technical
and clinical side. Extensive testing and
training prior to this can help alleviate
some of these issues but there will always
be unexpected teething problems. The
question is, are you going to let these issues
turn into something larger? Reacting to
clinical feedback is the key to stopping the
generation of systemic breakdown.

Use them before
The next points could easily be combined
as ‘clinical engagement’ but given some of
the issues with previous IT projects, breaking this down into three sections is actually
integral to success. When you build anything complex in health IT, you must plan
the clinical landscape before even discussing procurement never mind installation. A
simple health app on a ward for nurses may
only have a small footprint, but something
like an EHR or a new A&E system will
have far reaching knock-on effects, which
if not planned for can easily lead to project
collapse and issues with patient safety. Mapping and conversing with all the potential
end-users and analysing their workflow is
critical here. Also, how about a seemingly
unique method – ask them what they want!
Frontline staff will tell you their issues, bottlenecks and inefficiencies, and believe me
if you’re a manager, you will have no idea

Use them after
Hopefully the initial launch will have been
a success, but the key to realising the true
potential of anything digital is its reliability and continuity. Remember that the
majority of frontline staff change roles
or locations every 4-6 months, and very
quickly you can have problems. Furthermore, how do you know if the installation
has been a success? Anecdotal feedback
is welcome, but a structured, consistent
feedback mechanism is necessary along
with quantitative measurement of the pre
and post installation metrics, both clinical
and financial. By constantly refining the
technology and the process, you will consistently satisfy the end-users.
A combination of the steps above will
hopefully assist in the creation of ecosystems, in whichever form they take,
that can improve healthcare provision
and patient outcomes. Unfortunately
they are too often overlooked. n