The lecture explores fundamental concepts in health informatics, emphasizing the roles of models, information, and information systems. It discusses how models serve as representations of reality tailored for specific purposes, aiding in understanding and diagnosing patient conditions. Furthermore, it outlines the structure and implications of systems, particularly information systems, in transforming data into actionable knowledge for clinical interventions.

1. Lecture 2: Models, information, and
information systems
Dr. Martin Chapman
Principles of Health Informatics (7MPE1000). https://martinchapman.co.uk/teaching

2. Learning outcomes
1. To understand three basic theoretical concepts in Informatics: models,
information and systems.
Informatics; the study of information: representation, processing, and how
it is communicated.
It all comes back to interventions…
2. To determine how models and systems, and the information they
produce when applied to data, allow us to understand a patient’s
condition, and act accordingly.

3. Lecture structure
Use models as our primary framing:
1. What is a model? (Models)
2. Using models to understand the world (Information)
3. Models with multiple entities (Information Systems)

4. What is a model?
Models

5. Abstraction
• An abstract model is simpler than the real thing.
• The model represents a snapshot of the real thing, which will
become more inaccurate over time.
• Choices have been made about what to include in the model.
• As a consequence of the above, lots of different models can exist
of the same thing.
The above shows us that an (abstract) model is built for a particular
purpose.

6. Instantiation
• In contrast to abstraction, we add more details when we build
something from a template model.
• The model will become dated over time, and less relevant to the
real world.
• A model is altered when we build something from it.
• As a result of the above, no two instantiations are exactly the
same.
This reinforces the idea that models are always built for a particular
purpose, as there is no such thing as a general-purpose (template)
model.

7. Abstraction + Instantiation
A model is both informed by the
world (abstraction) and can be
realised in the world
(instantiation).
This may be a literal realisation
(e.g. building an aeroplane) or a
realisation that allows us to
understand the world.
Abstraction Instantiation

8. 2. Using models to understand the world
Information
Why might we build a model?

9. Understanding how our model works
We may have built a model with the purpose of understanding
whether planes float on water.
We can test our model and come up with some observations:
1. With pontoons, our model floats.
2. Without pontoons, our model sinks.

10. Understanding how the world works
Knowledge, from our model: If a
plane does not have pontoons, then
it will sink.
Data: The plane does not have
pontoons.
Information = Knowledge (model)
+ Data: The plane will sink.

11. Information model types
Knowledge, from our model: If a
plane does not have pontoons, then
it will sink.
We refer to this type of model as an
inference procedure.
It is supported by three other (sub-)
information models:
(1) A data model
(2) A knowledge base
(3) An ontology
We can break down the actual content
of our model…

12. (1) Data model
Thing B?
Thing C?
Thing A?
By themselves, things in our model are really just symbols.

13. (1) Data model
Propeller
Plane
1. Plane terminology: ‘Pontoon, propeller, plane…’
Pontoon
We need a language to describe planes:

14. (1) Data model
1. Plane terminology: ‘Pontoon, propeller, plane…’
2. Plane grammar: ‘Pontoons attach to planes, propellers attach to planes…’
We need a language to describe planes:
Propeller
Plane
Pontoon

15. (1) Data model
This language, our data model, then allows us to label and quantify the
data we have in the real world. This is often referred to as a database.
Plane
Pontoon = 0
Propeller = 1
Language Data
Propeller
Plane
Pontoon

16. (2) Knowledge base
Planes without pontoons will sink.
Planes without propellers cannot fly.
The difference between inference rules and a knowledge base is subtle.
Inference rules are often of the form ‘If X then Y’, whereas our knowledge base consists of
statements.
Inference rules formulate our knowledge so that it can be applied to data.

17. Planes without pontoons will sink.
Planes without propellers cannot fly.
(3) Ontology
To keep order in our knowledge base, we introduce an ontology (a
formal conceptualisation of the world).
A data model for our
knowledge base

18. Planes without propellers cannot fly.
Planes without pontoons will sink.
(3) Ontology
To keep order in our knowledge base, we introduce an ontology (a
formal conceptualisation of the world).
Our ontology tells us the concepts we can have in our knowledge
base…
Plane parts State

19. Planes without propellers cannot fly.
Planes without pontoons will sink.
(3) Ontology
To keep order in our knowledge base, we introduce an ontology (a
formal conceptualisation of the world).
Our ontology tells us the concepts we can have in our knowledge
base…
…and the relationship between those concepts, e.g.
‘Plane parts affect state’
…this stops invalid knowledge, such as ‘Planes without pontoons
cannot propellers’ (Plane parts affect plane parts).

20. Knowledge acquisition and application
In this way, we see how models
can capture knowledge that has
been gained from the world, and
in turn apply that knowledge to
the world. Abstraction
+
Knowledge
Acquisition
Instantiation
+
Knowledge
Application
Instantiation is not now building from the
model, but instead applying knowledge from it

21. Knowledge Limitations
Recall that models always capture particular parts of a domain
depending on their purpose.
In our running example, we are interested in determining whether
planes float, and included pontoons in our model accordingly.

22. Knowledge Limitations
However, these decisions often limit the knowledge a model can
contain, and thus its applicability.
For example, as it includes pontoons, we cannot use or model to
capture knowledge that can be used to determine whether a plane with
wheels can land on the ground.
NB. We also need to consider the language used in our model, and
how widely it can be interpreted.

23. Aside
Models are more than just physical replicas

24. Models are more than just physical replicas
So far we’ve been thinking of physical models as real, physical
replicas we can interact with in the world to gain some
understanding (e.g. a Lego plane).
It is good to anchor your understanding to this idea.
In reality, models can be more than this, and everything we know
about them so far still applies…

25. Example 1: A computer program
As a simple advancement, we
could consider a plane we realise
in a computer as a model rather
than a physical plane.
We still abstract, use that
abstraction to gain some
knowledge, and apply that
knowledge to understand the
world (with limitations).
Abstraction Instantiation

26. Example 2: Clinical guidelines
Clinical guidelines are also an
example of a model. They capture
knowledge about the world based
on clinical understanding, which
can then be applied back to new
situations.
Note that a model like this may be
purely held in a clinician’s head.
These are known as mental models.
Abstraction Instantiation
More to come on guidelines!

27. 3. Models with multiple entities
Information Systems

28. Models so far…
So far we’ve only considered our model as consisting of a single
entity, such as one plane.

29. Systems
Abstraction Instantiation

30. Systems
Abstraction Instantiation
If we capture
multiple entities, we
are instead creating
a type of model
known as a system.

31. Features of a system
Systems (models):
1. Have inputs and outputs
2. Have emergent behaviour
3. Are impacted by their environment
4. Have component parts
5. Can operate on feedback
6. Are arbitrary and purposive, like regular models
We’re still going to use physical models for these examples, but remember models are more than just
physical replicas…

32. 1. Inputs and outputs
Passengers are the input to our system, and their
arrival at their destination is the output. There is
a transformation.
The state of the entities in the system is also
affected by these inputs, such as the location
of the planes.

33. 2. Emergent behaviour
Planes have individual
behaviours that we know
about and distinguish
them from the
environment around them,
such as flying.
However some behaviours, such
as the route taken, we cannot
know in advance, as they are
dependent on the behaviour of
other entities in the system (e.g.
other routes taken). This is
known as emergent behaviour.

34. 3. Environment impact
A significant factor in
emergent behaviour is
the impact of the
system’s environment.
A plane having to change its
altitude mid-flight, for
example—thus affecting the
routes of other planes
(emergent behaviour)—might
be due to the weather.

35. 4. Sub-systems The entities in a system
can often be grouped
together to form sub-
systems.
In our example, we can
consider different airspaces
as different sub-systems.
The outputs from one sub-
system often form the
inputs to another.
For example, information
about having one less
plane in a given airspace is
input as one additional
plane in another.

36. 5. Feedback When the same sub-system
both gives output and
receives this as input, we call
this feedback.
Feedback is typically
mediated by a central control
sub-system
Positive feedback moves a system from one state to another, while negative feedback restricts
a system to operating within a certain state. Our controller might combine the two to allow a
plane to move from one airspace to another, but not to return, so the journey progresses.
The plane has left, now
do not let it return.

37. 6. Systems are purposive and arbitrary
We explored several properties of models earlier.
Two key observations were that (1) abstract models are built for a
particular purpose (there is no such thing as a general-purpose
model) and, as a consequence, (2) lots of different models can exist
of the same thing.
The same is true of systems (models):
1. They are built for a purpose, e.g. exploring optimal approaches to
air traffic control (purposive).
2. They is no such thing as a correct system definition; many exist
(arbitrary). Many different ways to model air traffic control.

38. What about knowledge?

39. What about knowledge?
Sinks
Data model (language) Labelled data
Knowledge base
Input
Output

40. Information systems
What we were really doing earlier when we were understanding
whether a plane was going to sink was applying a special type of
system where the interacting components are models themselves (!).
Much like the systems we’ve seen, there are inputs and outputs,
components interact, etc.
This type of system is known as an information system.
The notion of an information system being a ‘model of models’ is a
little tough, so here’s another example:

41. A calculator as an information system
Sinks
1 + 2 X, Y
X=1,
Y=2
Data model (language) Labelled data
Knowledge base
Input
Output
3
Z = X + Y

42. A calculator as an information system
Sinks
Abstraction Instantiation

43. Automation
Capturing knowledge in this way is useful, because we can then
provide it to a computer in order to automate its application.
If we cannot fully represent the model in a computer, then human
intervention may be required (semi-automated).
Similarly, computers may play more of a supportive role, organising
data or providing visualisation of that data.
Sinks

44. It all comes back to interventions…
If we can automate the application of knowledge to health data,
then we can automate (the introduction of) interventions.
If we can’t fully use information systems to automate this
application, then they can assist clinicians in the delivery of
interventions.
Diabetes

45. Summary
• ‘To understand three basic theoretical concepts in Informatics:
models, information and systems.’
• Models are (imperfect) representations of the world, built for a
particular purpose.
• Models allow us to transform data into information
• A system is a model with multiple components, and an
information system is a type of model that, as stated,
transforms data into information, using component parts that
are, themselves, models.

46. Summary
• ‘To determine how models and systems, and the information they
produce when applied to data, allow us to understand a patient’s
condition, and act accordingly.’
• (Mental) models support diagnosis and treatment in clinical
practice.
• Information systems present the opportunity to automate these
processes.

47. References and Images
Enrico Coiera. Guide to Health Informatics (3rd ed.). CRC Press, 2015.
https://www.lego.com/en-gb/service/buildinginstructions/3178
https://lemonbin.com/difference-between-seaplane-floatplane/
https://www.youtube.com/watch?v=EeY77RoNwz8
https://www.nbcnews.com/science/science-news/largest-electric-plane-yet-completed-its-first-flight-it-s-n1221401
https://www.cnet.com/tech/gaming/microsoft-flight-simulator-takes-flight-on-xbox-game-pass-tuesday/
https://www.healthline.com/health/ozone-therapy
https://www.toypro.com/en/product/43771/eileen

48. References and Images
https://www.brickowl.com/catalog/lego-house-building-set-lady-minifigure
https://insight-egypt.com/jvaa.php?iid=119951709-lego+minifigure+camera&cid=28
https://www.theminifigurestore.uk/shop/sea-rescuer-series-20-lego-minifigures-71027/
https://www.toypro.com/no/product/25988/wave-angular-lightning-bolt/trans-light-blue
https://www.lego.com/en-gb/product/passenger-airplane-60262
https://www.airport-technology.com/news/birmingham-airport-flight-data-display-system/
https://www.casio.co.uk/fx-83gtx-pink