Download available here - I`ve Been Thinking

Health information systems.
The case for a problem oriented architecture approach.
Dr Bernard Robertson-Dunn
[email protected]
Bernard is an independent consultant working in the fields of Enterprise Architecture and Problem Solving.
Sydney Australia.
This is a revised and extended version of a paper presented at
the Enterprise Architecture Conference in Sydney September 2015
http://enterprisearchitectureconference.com.au/
Executive Summary. The application of IT to the Health industry has had mixed results. Many of the simpler
applications, such as diagnostic and other devices as well as administrative systems have had reasonable
success. This paper concentrates on health information systems that support health care decision making. The
objective of this paper is to review nature of the problems that Health information systems attempt to solve and
makes the case for a much more sophisticated and advanced approach than that used in industries with more
standardised business processes. It is based upon the recognition that health care is a wicked problem, beset by
uncertainties, multiple stakeholders and competing objectives. In addition the introduction of automated health
care information systems is being used to increase efficiency and effectiveness by changing health care decision
making processes, something that is likely to change the nature of the problem of health care decision making,
thus reinforcing its “wickedness”
Introduction
The health care industry uses information technology in a wide variety of ways.
There are technology based devices that implement very fixed and well defined rules such as blood
analysis tools, X-Rays, CT and MRI scans. These devices measure, analyse and create health data on
a particular patient which are then used in subsequent health care decision making processes. The
devices themselves have little or no “knowledge” of the patient; privacy and security are easily
handled and improvements and changes in the performance of the technology do not tend to create
new or difficult problems.
There are relatively standard business information systems such as appointments management,
practice and clinic management, business accounting, financial management, HR systems,
prescription management etc. These are, in type, not very different from other business information
systems. The business rules may be complex but they are relatively constant and identifiable.
There are technology services such as secure messaging systems, standard data coding (e.g. HL7) that
can be developed and implemented as infrastructure. These are complex systems, but do not store
much, if any, specific personal or health related data.
Authentication and authorisation systems store personal data, they do not contain patient health
information but they are essential to the operation of health information systems. Many of the
problems of authentication and authorisation systems, in the context of health care, are driven by the
problems and solutions of health decision making. There is a strong relationship at the problem level
and it is essential that the interactions be well understood and properly managed.
Decisions regarding the authentication of users of health information systems can have significant
impact on their acceptance. For example, there are different ways to control access to a patient’s
health record. Access can be based upon a range of factors including:
1. a health care professional’s identity;
2. the institution a health care professional works for;
3. the nature of the institution a health care professional works for;
4. the role of a health care professional; and
5. the relationship the user has with the patient, e.g. carer, parent etc.
This is not a comprehensive list; it is dependent on the scope of the health information system. The
greater the scope of a system (e.g. a GP’s practice vs. a national eHealth record) the more difficult is it
to identify and manage the problem. Unfortunately, the greater the scope, the more important it is that
the problem be solved to all stakeholder’s satisfaction.
The most valuable use of IT in the health industry is in support of health care. Health care has two
major phases:
1. The process of decision making i.e. analysis and diagnosis of a patient’s condition and the
prescription of an appropriate course of treatment; and
2. The implementation of that treatment and the monitoring of progress, or otherwise.
In terms of information needs, health care decision making is by far the more difficult. Health care
professionals need access to patient data that is accurate, timely and relevant. They also need access to
data on other matters, including current treatments and procedures as well as on the availability of
health care facilities. The information required for health decision making is not just a matter of a
patient’s health record.
It is worth noting that health care has been identified and discussed by the Australian Public Service
Commission as a wicked problem as far back as 2007 [1]. It would appear that current attempts in
Australia at implementing an eHealth record, have not accepted this advice and efforts have
proceeded on the basis that an eHealth record is just like any other database. The rate of uptake and
use of this national IT system have been disappointing [2].
In addition to the complexities of health related decision making, health professionals and the
institutions they work for are under an increasing pressure from governments and other sources of
health care funding to improve the effectiveness and efficiencies of the health industry. This increases
the objectives of health care systems, often in ways that reduce the opportunities of health carers to
achieve good health outcomes, which should be the primary objective, but which usually isn’t.
The scope, uncertainties and complexities of health decision making mean it is very difficult, if not
impossible, to define standard processes such that they can be automated by information systems or
even by humans with the support of information systems.
This lack of understanding of the difficulty of addressing problems in health care mean that the
thinking behind many initiatives in Health IT, which assume that the advances achieved in other
industries can be replicable in the health industry, is misplaced.
This paper discusses the nature of health care decision making and the challenges facing those
charged with developing Health information systems that support such decision making processes.
Health Information Systems
Many non-health business processes have been successfully automated. These include processes such
as business banking and investment, order acceptance and processing, manufacturing, CRM, ERP, all
of which have relatively standard data management requirements and business processing rules. The
range of people who use many of these systems is also fairly well known and can be controlled, at
least to a reasonable extent.
Human health is a much more complex and uncertain discipline and is far less often driven by
standard processes and practices. In addition, the scope of users of health information is far wider and
variable than the average business system. For example, some health information systems such as
record systems in a GP’s practice or hospital have quite closed user communities. These users have
close relationships with their health care institution and access is limited to only a small group of
known staff. It is very rare that these systems are exposed to the public internet or accessible by
patients. The stakeholder groups of these systems are also reasonable small, usually only people
directly associated with the institution.
However, when it comes to larger, nationwide health record systems, systems which attempt to
consolidate a patient’s complete health records into a single viewpoint, the number of stakeholder
groups increases significantly. These stakeholder groups include:

Patients, who want their health issues addressed, preferably quickly, cheaply and often,
without too much effort on their own behalf. They also want individual and tailored care.
They want their health information to be treated as private, but be readily available when
needed, but only to those who have a valid need.

Health professionals, who have a range of different objectives. They want to provide valuable
services to patients, but they often also need to be concerned about the financial aspects of
their work. This group usually claim that they want to see all of a patient’s health record
because they cannot define what may or may not be relevant or important until they see it.

Funding bodies that want to reduce, or control, expenditure.

Pharmaceutical and other medical oriented organisations, that want to increase their revenues
and profits. They may have a vested or even conflict of interest in the health care industry.

Research bodies, including universities, governments and commercial enterprises such as
device makers and pharmaceutical companies that would like access to “big” health data.

Insurance companies and, in some cases, courts and legal institutions, who may want access
to health data of individuals.

Security and law enforcement institutions that see benefits in accessing the rich data
repositories associated with health care and allied authentication systems.

Regulatory bodies, who are charged with ensuring that medically related goods and services
meet the appropriate legal standards and requirements.

Information Technology product and service providers, who want to participate in the
development, implementation and provision of health related goods and services.
The sheer number of these stakeholder groups, the above is only a subset, and their various and
disparate needs have a major and complicating impact on the development and use of health
information systems. They impose constraints and requirements on information systems and, in
solving their own business problems, create requirements on and for other solutions.
Health Information
The decision making process at the heart of health care is critically dependent on quality information
on, and from, a wide variety of sources.
The most important and critical aspect of Health Information is the simple fact that much patient data
is inherently unreliable. A patient is a constantly changing, dynamic system. Tests, symptoms,
diagnoses, opinions all occur in a particular context, at a particular time. The context usually changes
and patients always change over time, either because they age or because of medication, treatment or
accidents. This means that the data in a patient health record should not be assumed to be accurate.
Some data may be – a patient had a knee replacement or was diagnosed with chicken pox; other data
may not be so reliable – a patient has a low iron count, high blood pressure, or is suffering from
depression. This lack of trust in much of the data in a patient health record means that many health
professionals do not rely on the data and order new tests or they discount what is in the record.
For health information systems to be effective and usable they should not concentrate just on patient
data but they should encompass all relevant information. Understanding what this data is requires a
huge amount of analysis of health care processes along with a deep understanding of the information
issues associated with these processes. To the author’s belief, this has very rarely, if ever, been
undertaken; certainly not on a national or other large scale basis.
This lack of understanding of the real and full nature of health information and the decision making
processes has not stopped many governments attempting to develop large scale eHealth record
systems, usually as an IT based initiative. The common, IT driven approach to health record systems
comprises:
Gather a patient’s health data into a single repository, convince the patient that this makes
health services “people-centred and integrated” and make it available to health care decision
makers.
This approach is, in part, driven by no less an enterprise than the World Health Organisation [3]. The
WHO states “Putting people at the heart of the health-care experience and focusing on a true and
lasting integration of services offered to them is urgently needed to meet the challenges faced by
today’s health systems, however diverse.”
This has, simplistically, been interpreted by many in the IT business as a call for large scale eHealth
Record systems; systems that just aggregate large amounts of undifferentiated patient health data with
no regard to the clinical efficiency of such data.
What the WHO and these IT system developers don’t explain is how “lots of data” will solve the
problem of how to achieve better health decision making and how the problems created by such a
simplistic approach should be dealt with. It is claimed, as an obvious but unjustified belief, that health
IT will automatically bring similar benefits to those automation projects that have been of benefit in
other industries.
As stated above, health information comprises far more than just a record of a patient’s health status
over time. When a health professional makes health care decisions they need access to a wider set of
data than just patient data including:

data and opinions from other professionals.

knowledge about current best treatments.

awareness of interactions between treatments and between medications.

the availability of subsequent care facilities.

guidelines on the effectiveness and efficiencies of prescribed treatment.
The need for particular health data also changes according to the needs of the health carer. It is highly
unlikely that the whole of a patient’s health data would be relevant to any single health issue.
However, knowing what is relevant and what is not can be problematic. Some specialists may only be
interested in a small subset; others may wish to see much more.
Although a particular specialist may not want or need to see all health data, in general the medical
community has often expressed a desire to be able to see all available information in a patient’s health
record, if necessary, in order to make the best decisions. On the other hand, the patient may not want
to make all their health record accessible to everybody involved in their health care or even to their
family or carers. The patient may have the view that only “relevant” information should be accessible
to a health professional, however defining what “relevant” may be is an impossible problem, one that
may change over time or over circumstances.
The more data in a system and the more systems being integrated can lead to significant issues with
data quality. The approach of making the patient responsible for data quality has potential problems
that may arise from assumptions about the patient’s ability and capability to manage their health data.
The volume of data in a health record system can be problematic. Too much data means a health
professional needs to read through, assess and absorb a large amount of information and make
decisions regarding its relevance and/or potential (in)accuracy. Managing large amounts of health data
and organising it effectively, without knowing beforehand what will be relevant in a particular
medical situation, is a highly complex task in itself.
Health care decision making processes
A banking transaction is a process that can be precisely defined and therefore is suitable for
automation. Middleware has been developed that does just this. On Line transaction Processing
(OLTP) software such as IBM’s CICS has been available for many years and is a problem is both well
understood and its solution readily available.
On the other hand, health care processes such as identifying a patient’s health status and any
conditions along with their severity, proposing and optimising treatment plans, patient care, managing
adverse drug reactions and the treatment of accident and trauma patients are not amenable to
standardised procedures. The problems associated with defining procedures are compounded by the
unreliability of patient health data, as outlined above.
The decisions that a GP or specialist makes when assessing and diagnosing a patient are not limited
just to the patient’s health record or their status. The health professional must also consider issues of
risk; risk to his personal reputation, his practice, the community as well as to the patient.
Issues of cost of tests and subsequent treatment may also be relevant. This is an area where
governments and other health funding organisations are tempted to apply pressure in order to reduce
un-necessary expenses. Acting in the other direction are medical and pharmaceutical companies that
would like to see an increase in the use of their products and services.
Overview of large scale IT system Development Processes
The development of health information systems may be considered to be a subset of the problem of
large scale IT system development. However aspects of health information systems, such as the
combination of the sensitivity of the data, the consequences of poor performance of the system, the
wide range of stakeholder groups and the enormous costs associated with health care probably mean
that the development of such systems is a unique challenge.
Looking at IT system development, there are many well proven methodologies, frameworks and
approaches; however, they all have a tendency to fail when it comes to large scale and highly complex
projects. It is no surprise then that, when applied to health information systems, the failure rate of
these approaches is no better.
It can be informative though to look at common reasons for the failure of these “traditional”
approaches.
Like any process, the quality of the output is critically dependent on the nature of the input. In the
case of most architecture approaches, the input is requirements. Analysis and studies into failed
projects usually cite bad requirements as the major cause.
In 1974 Russell Ackoff [4] said
“Successful problem solving requires finding the right solution to the right problem. We fail
more often because we solve the wrong problem than because we get the wrong solution to
the right problem”
In other words, we have not learned much from all these failures.
Getting back to requirements, the main reasons requirements are bad are
1. someone has made a stuff up of solving the original business problem, and so the
requirements are not valid; and
2. no-one has understood the problems that will be created by the proposed solution, and so the
requirements are not complete.
Furthermore, when the requirements are not valid or complete, they will almost certainly keep
changing over the life of the development project.
If a requirements driven approach fails to deliver when applied to large scale and highly complex
projects, then a different approach is needed.
In the author’s paper "Beyond the Zachman framework: Problem-oriented system architecture" [5],
when discussing the role of frameworks, it was pointed out that:
“In the framework approach, solving the problem is deemed to be the responsibility of the
business system owner. Although the framework architect works with the system owner, it is
in order to identify solution requirements, not to question if the problem has been formulated
or solved appropriately.
Frameworks rely on the business system owner being able to define the requirements of their
solution. The assumptions behind this technique are highly questionable. Edward Yourdon, in
Rise and Resurrection of the American Programmer in 1997, observed that it is not possible
to identify user requirements completely and accurately. Users rarely know what they want
and are even less able to articulate it. Even if they can, the requirements are highly likely to
change during the conduct of the project. The only things that have changed since Edward
Yourdon made these observations are that the business and technology environments are far
more complex, uncertain and changeable, the consequence being that it has become even
more difficult for users to solve their problems and then identify and communicate
requirements.”
If it were just a matter of improving the requirements gathering and identification process, then maybe
better project management techniques would be sufficient. However, the nature of health information
systems (poorly understood processes) and the need to change the way health care is delivered means
that simple and obvious solutions are probably wrong.
A problem oriented approach
There are three major characteristics of health information systems that strongly suggest that a focus
on the problems associated with health care should be the fundamental basis on which any strategy or
program development initiative is built. These characteristics are:
1. Health decision making processes are many, varied and difficult to define;
2. There are pressures to increase effectiveness and efficiency, which are more than likely to
result in changes to health decision making processes; and
3. Managing health information is a difficult problem in its own right.
A problem oriented approach to information system development has been proposed in two
publications, to which the reader is referred for a more detailed description [5, 6].
In summary, a problem oriented approach focuses on the questions that need to be answered in order
to achieve business objectives. The answers to these questions – the solutions – must also be
considered and fully understood in order to identify the problems that these solutions will create.
A problem oriented approach treats architecture and system development as a dynamic process that
has as its desired outcome a solution to a problem that, when solved, is of value to the business. The
solution may be implemented as a strategy and/or architecture within which further development can
occur or a specific system.
The approach is an iterative process of: identify goal, formulate problem, predict one or more
solutions, measure solutions against problem, measure problem against goal. The iterations either stop
or become less frequent when an optimal solution has been selected and moves into implementation.
The iterations need to continue to ensure that subsequent decisions do not change the solution or to
ensure that the goal or problem have not changed, requiring modifications to the solution.
The iterations move though various phases, recognizing that the basis on which previous decisions
were made may change. At some point it might be acceptable to assume that the problem has been
identified and remains constant. At another point, the assumption that the requirements will remain
stable and constant could be safely made. In order to reduce risk, however, it is necessary to check
that these assumptions are valid.
Other important characteristics of a problem oriented approach are:
Goals, Problems and Solutions:
Solving a problem has value because it achieves an objective. A solution costs money, but if it doesn’t
solve the right problem it will deliver no value.
You cannot tell what problem a solution is intended to solve by just looking at the solution.
Problem Types
All problems are not the same. There are three types of problem which require different approaches to
solving.
A Tame problem can be solved in a linear fashion using straightforward, reductionist, repeatable,
sequential techniques. They are amenable to traditional project management approaches and they
introduce limited/known/manageable consequences and no unintended consequences. A Tame
problem is well defined, its solution is clear and can be given to a designer to create detailed
specifications and project manager to implement.
Complex problems tend to be non-linear, difficult to understand and their solutions can lead to other
problems and unintended consequences. All problems involving new technology, new development
environments or new applications should be considered to be complex.
Traditional analytic and project management techniques will most likely fail. A complex problem is
not solvable by reductionist or sequential approaches.
Some complex problems are just very difficult and require a lot of effort but a successful outcome is,
at least in theory, achievable.
Wicked problems are the hardest to solve and have an overlap with complex problems. Wicked
problems are where goals are either not known or ambiguous, and means-ends relationships are
poorly understood. Wicked problems were first discussed by Rittel and Webber in 1973 [7] and
related to social systems. It should be noted that information systems that have significant end user
involvement will probably be wicked. The majority of the characteristics of the problem that will
cause trouble will be around human behaviour, not the IT infrastructure.
Partitioning
Partitioning is a process by which different aspects of a problem can be modelled from a variety of
perspectives. Understanding a complex or wicked problem cannot be done by looking at its
constituent parts. The consequences of inter-relationships and emergent behaviours are only visible
when viewing the problem as a whole.
Complexity and wickedness arise because of their non-linear characteristics and non-linear systems
cannot be understood by simplifying, by partitioning or any other mechanism without destroying the
relationship between the understanding and the reality of the problem. The concept of “taming” a
wicked problem is fatally flawed.
Partitioning a solution into subsystems may help system development, but unless the solution is
recombined and its behaviour measured as a whole, there is no guarantee that the total system will
work, when finally implemented.
Feedback
A problem oriented approach makes significant use of the principle of negative feedback. This is a
technique that compares the input to a process with the output of that process. Corrective action is
taken if there is a discrepancy. By treating strategy, architecture and development activities as a
dynamic process and applying feedback techniques to that process, there is an increased likelihood
that an optimal outcome will be achieved.
To properly connect the problem space with the architecture and system development process, it is
essential that the problem itself be part of the feedback loop. Bringing the problem into the feedback
loop has a number of benefits. The first is that the business goals associated with the problem are
subject to analysis and scrutiny. In other words, the problem itself is questioned to ensure that its
solution still achieves the business goals.
Secondly the behaviour of the predicted solution is compared with the problem, not the requirements.
This will mean that external disturbances, consequential problems and uncertainty and change will
automatically be addressed as part of the process. If the predicted solution does not solve the problem
and solving the problem does not meet the goals, some form of corrective action will need to be taken.
The difference between a complex and a wicked problem lies in certainties and relationships in the
problem space. The feedback loop around a wicked problem needs to have strong links to all the
stakeholders in both the problem and solution space. A complex problem probably has fewer
stakeholders in the problem domain than does a wicked problem.
The problem solving and solution development process gradually increases its scope as a project
advances. Initially it generates solution options; the feedback process converges on a preferred,
predicted solution which is followed by design and construction. The feedback process continues to
operate; concentrating on ensuring that subsequent decision making continues to lead to a solution
that solves the problem.
Comparisons
It is a fundament tenet of control theory that, if something cannot be measured, it cannot be
controlled. Measurement can take one of two forms, counting or comparison. In the context of system
architecture, what needs to be measured is the solution with respect to the problem that needs to be
solved. In a project that is based upon the framework approach, measurements are usually only of the
counting type, those of time and cost. If the solution is ever measured it is usually compared with
requirements, not with the business goals or the problem that needs solving.
However, in architecture and system development, measurements and comparisons are not easy. In
industrial control systems the output can usually be compared in some direct way with the input
signal. In the case of architecture and system development the output at any one time is not the
intended solution but a representation of the solution. In fact any architecture or design artefact is best
considered to be a prediction or estimate.
Unfortunately, a predicted solution cannot be directly compared with a problem. The problem and its
solution are different things. It is necessary, therefore to translate from the solution domain back into
the problem domain. Part of this translation should include a recombination of the components that
have been introduced because of partitioning, into a complete system. Another is to identify the
behaviour of the predicted solution.
A Problem Oriented Approach to Health Information Systems
To take a problem oriented approach to health information systems is to recognise that there is a high
degree of uncertainty in the goals and problems associated with a health care system.
Sometimes the problem needs to be studied more fully and carefully before even attempting to define
a solution or develop a system architecture. Answering some of these questions may lead to a range of
domain architectures (e.g. business information and processes architectures that describe,
conceptually and logically, the problem domain). These problems include:

Who are, and what are the relationships between, stakeholder groups?

What are the common characteristics and processes that underlie health care decision
making?

What information is required to support health care decision making?

What relationships exist between patients, health care decision makers and other providers of
health products and services with respect to the delivery of health services?

What is the life-cycle of health information?

What are the issues regarding trust and how should trust be managed in a health information
system?

Are all stakeholders, their needs, their ability and their capability to actively participate in a
health information system the same? If they are not, should there be a single system that
meets the lowest common denominator, or multiple systems that meet the requirements of
different patient groups? Or some other approach? And remember, there are more
stakeholders than patients involved in health information system. Medical products and
services are included, amongst others.

How are disputes regarding data in a health information system resolved?

What are the measures of data accuracy?

What are the dangers in collecting large amounts of highly personal patient data?

What is the trade-off between privacy and good health care? Who makes that trade-off? Is it
done on a systemic basis or on a patient by patient basis, or a condition by condition basis, or
what?

Should patients have direct access to their health data? Should it be moderated?

How can the data in a patient’s Health Record be made accurate and be maintained in order to
keep it accurate?

If patient data is not accurate, who is responsible for correcting it and how is it to be
corrected?

Is patient data current? (The data could be accurate in that it represented the patient’s status at
some time in the past but it no longer reflects the patient’s current status)

Who should be permitted to view personal data?

What is an acceptable access control model? Is a single model appropriate for all users?

How much effort will be required by a health professional to identify relevant data in a health
record?

Where there is a potential conflict of access (e.g. a patient not wanting all health professionals
to see irrelevant data versus health professionals wanting to see the entire patient’s data),
which viewpoint takes precedence? How is this achieved? Does it change according to
circumstances?

What relationships exist between patients and non-health carers (e.g. other family members)
with respect to information flows? How does this relate to the data models that are
implemented in the system?

What are the relationships with other health information systems?
It is highly likely that these questions cannot be answered independently. In other words, there will be
non-linear dependencies between them – a characteristic of wicked problems.
Another characteristic observed by Rittel and Webber is that you only get one chance to solve the
problem. In other words, the big bang approach is almost certainly going to lead to failure. Whatever
solution you put in, the problem will morph around it, making the solution useless. In some cases, the
problem becomes even harder to solve because you now have a useless solution as part of the new
problem.
The conclusion could be that a wicked problem is unsolvable. It is highly likely that the problem of
Health information systems, as currently understood and stated means this is probably correct.
What does that mean for those trying to improve the effectiveness and efficiency of health care? If the
goals remain the same, and the current perspective of the problem will only lead to failure, then the
only sensible answer is to change the problem.
There are a number of potential options:
1. Try to solve a subset of the original problem or problems, knowing that other subsets will be
required and that some or all of the subsets will probably need to be thrown away.
2. Try to solve the original problem or problems, but in a limited context (this is a specific
version of option 1). Based upon experience and various iterations of solutions, extend the
solution to the wider context.
3. Try multiple solutions, each in a limited context and select the best or let natural selection kill
off the less successful ones.
4. Do not even try to solve the problem, but fund others to come up with their solution options
and implementations.
This is not a complete set of potential solutions, or even a discussion of what the problems are or
should be seen as.
It is worth looking at a not dissimilar problem of the past. How to architect an international data
communication system – the Internet.
There were two proposed solutions. One was based upon a highly engineered set of standards,
protocols and architecture models - Open Systems Interconnect (OSI). This was a technically elegant
approach that came out of work by the International Organization for Standardization (ISO), and the
International Telegraph and Telephone Consultative Committee (CCITT).
This approach would probably have prevented or reduced many of today’s security and performance
problems; however it was seen as a slow process and did not address all the, mainly non technical,
issues.
The other approach was TCP/IP that came out of work funded by DARPA, an agency of the United
States Department of Defense and performed mainly by the IETF (the Internet Engineering Task
Force). Their approach was, in effect, the Nike slogan – just do it. A simpler and less comprehensive
set of protocols were developed in order to get something working. This had the advantage of rapid
development cycles, and a framework that everybody could get going with and which could be built
upon, layer by layer. This solution is far from ideal, but at least something is up and working and the
Internet is never going to go away. Fixing the subsequent problems is quite a challenge, but the
alternative approach may have had technical problems of its own and progress would have been a lot
slower.
The above are gross simplifications of the technology and the processes; however, the “take away”
lessons are that neither solution has, or would have, fully solved all the problems of the Internet. But
the TCP/IP route did lead to what we have today and was built upon a distributed solutioning space –
i.e. many people working, collaboratively¸ on different subsets of the problems. The only criteria
being that it worked.
This is not a suggestion that the problems of health care are in anyway similar to those of digital
networking. It is used as an example of how different approaches are possible and how non-technical
issues can often be major drivers for solutions to what seem to be technical problems.
Conclusions
Health care is probably an order of magnitude more difficult set of problems that just about any other
domain. It is not often that people die because of poor engineering decisions made in the development
of the Internet or because a TV or computer has been badly designed. The health care industry cannot
afford to make systemic mistakes leading to large scale bad health outcomes.
To repeat a tenet of the problem oriented approach – the solution to one problem is probably not the
solution to another. The development of health care information systems will need approaches of its
own. Potentially different for each country because of cultural issues; potentially different for each
scale and scope of system because of stakeholder group differences; potentially different for each
health care domain – mental health is not the same as orthopaedics, is not the same as virology, is not
the same as endocrinology etc.
The message in this paper is based upon understanding that health care decision making and
associated information systems are far more complex than most business and government systems that
have been developed to date. The track record of the development of these systems has not been very
impressive, health systems are even more of a challenge and so require a different approach.
Health information systems form part of a highly complex decision making ecosystem. The problems
to be solved in developing these systems are multi-faceted, have a wide range of stakeholders and will
change over time as new systems are implemented and the behaviours of the participants also change.
Current “requirements” based approaches to large scale IT system development are akin to open loop
systems. Follow a standard approach and a known result will ensue. The embarrassing failure rate of
large scale IT systems demonstrates that this approach is fundamentally flawed in anything but the
simplest of systems development projects.
What is required is an approach that focuses on, and is driven by, problems and goals, that recognises
that the problems are likely to change and that human health and human behaviour are at the core of
health systems. What is most important is that the nature of Health Information is recognised as being
different from that in most other automated systems. This difference means that the traditional
approach to Information System development should not be applied to patient health record systems.
It also means that it is difficult, if not impossible to develop automated systems that deliver high value
outcomes in the same way that has been achieved in other industries.
A problem oriented approach is not a methodology – it is a philosophy, a direction, a way of thinking.
It is the mental equivalent of a negative feedback control system which includes the problem in the
loop, constantly monitoring the predicted solution against the problem it is intended to solve.
There are no clear cut answers to the problem of improving health care by the use of information
systems, however, to summarise the philosophy of a problem oriented approach: if you lose sight of
the problem, you’ll never get a decent solution.
References
[1] “Tackling Wicked Problems: A Public Policy Perspective” Australian Public Service Commission
Available at http://www.apsc.gov.au/publications-and-media/archive/publications-archive/tacklingwicked-problems
[2]
Review
of
the
Personally
Controlled
Electronic
Health
Record
Available at http://www.health.gov.au/internet/ministers/publishing.nsf/Content/health-mediarelyr2013-dutton028.htm
[3] “WHO global strategy on people-centred and integrated
http://www.who.int/servicedeliverysafety/areas/people-centred-care/en/
health
services”
[4] R. L. Ackoff, Redesigning the Future: A Systems Approach to Societal Problems. New York: John
Wiley & Sons, 1974.
[5] "A Problem Oriented Enterprise Architecture Approach Applied to Wicked Problems" in
Enterprise Architecture for Connected E-Government: Practices and Innovations, edited by Pallab
Saha, National University of Singapore, Singapore. June 2012
[6] "Beyond the Zachman framework: Problem-oriented system architecture" IBM Journal of
Research
and
Development.
Volume
56,
Issue
5,
September/October
2012
available at http://www.drbrd.com/docs/Problem-orientedSystemArchitecture.pdf
[7] H. Rittel and M. Webber, “Dilemmas in a General Theory of Planning,” Policy Sciences, vol. 4,
pp. 155–169, 1973. Available http://www.thestudiony.com/ed/bfa/Rittel+Webber+Dilemmas.pdf