29/09/2015
Model Development Guidance
Date: 03/02/2016
Status Ver 1.0 (Draft)
Distribution All members of MOCHA
Context This is a guidance document for developing information and process models for child health
services in preparation of the MOCHA WP1 workshop to be held on 8th March 2016.
Authors Simon de Lusignan, Harshana Liyanage, Filipa Ferreira (University of Surrey)
Report name: Model Development Guidance
29/09/2015
Introduction
We have planned to explore various types of models that can be used to represent the
information and processes in child health systems during the MOCHA WP1 workshop to be held
on 8th March 2016.. The suggested methods will allow modelling systems in multiple
perspectives, thereby, giving deeper insights into how complex systems operate in real world
scenarios. This is particularly important when elucidating the technical requirements that will
lead to specifying and building datasets that will eventually be analysed in studies conducted
within the MOCHA project. The techniques suggested to be used to model these multiple
perspectives are to be used in the project are illustrated in Figure 1.
In this guidance document, we aim to introduce basic notations (for understanding the models),
tools (for developing the models) and typical examples of their usage.
Figure 1: Multiple perspectives of a system
Rich Pictures Rich pictures are used to encourage “systems thinking”(Systems thinking is the process of
understanding how those things which may be regarded as systems influence one another
within a complete entity, or larger system).1 This is particularly useful due to the complex
nature of today’s health systems. This method was originally introduced by Peter Checkland as a
part of the Soft Systems Methodology.2
A Rich picture shows an unstructured description of a system or a situation. This is often helpful
to identify where particular issues exists within a complex system. These illustrations are
developed usually by interviewing people that operate within the system. Unlike other
techniques there are no rules or constraints for drawing the diagrams.
Report name: Model Development Guidance
29/09/2015
Figure 2: Rich picture example- Rich picture illustrating illness
Figure 3 - Rich picture example- Comprehensive health provision in Redbridge (London)
Report name: Model Development Guidance
29/09/2015
Figure 4 – Rich picture example - How public health & health policy impacts on T2DM
Element Comment 1. Include structure Include only enough structure to allow you to record the
process and concerns. 2. Include process Do not attempt to record all the intricacies of process; a
broad brush approach is usually all that is needed. 3. Include concerns Caricature the concern in a thought bubble. A detailed
explanation may be provided in a supplementary document.
4. Use the language of the people depicted in it
This will make the rich picture comprehensible to your informants.
5. Use any pictorial or textual device that suits your purpose
There is no correct way of drawing a rich picture!
Table 1: Elements of an effective rich picture3
Resources:
How people use Rich Pictures to help them think and act: http://bit.ly/1SsuS9U
Diagramming for development 1 - Bounding realities: http://bit.ly/1RZZOxG
Tools:
Most Rich Pictures are drawn as hand drawn diagrams. However, the following tools also may
be helpful for developing Rich Pictures.
Microsoft Powerpoint
Microsoft Visio
Insight maker (Web based) https://insightmaker.com/
o Tutorial: https://www.youtube.com/watch?v=pq0uv9Kh-vk
Report name: Model Development Guidance
29/09/2015
Data Flow Diagrams
A Data flow diagram (DFD) is a graphical representation of the data flow within an information
system. This technique is used to clearly and concisely communicate the flow of data through a
system. It concerns details regarding where the data will come from and go to as well as where
it will be stored. DFD’s are easier to understand than textual representations. Data flow
diagrams can be made in several nested layers if a system needs to be described in greater
detail. A single process node on a high level diagram can be expanded to show a more detailed
data flow diagram. An example DFD representing the data flow associated to a GP practice are
given in Figure 6. The instances of the different elements used in the example are given in Table
2.
Figure 5- Symbols used in data flow diagrams4
Tools:
Microsoft Visio
https://www.draw.io/ (Web based)
Resources:
How to Draw Data Flow Diagram? https://www.youtube.com/watch?v=ztZsEI6C-mI
Data Flow Diagrams http://www.eis.mdx.ac.uk/staffpages/geetha/bis2030/DFD.html
Models and modelling - Data flow diagrams - http://bit.ly/1nMRftE
Report name: Model Development Guidance
29/09/2015
Figure 6 – Example DFD – GP Practice system
DFD element Instances in the DFD Entities Patient, GP, Pharmacist Process Patient registration, GP appointment, GP
consultation, Medicine collection Data Store Patient database, clinical event data, pharmacy
inventory, pharmacy financial ledger Data flows Patient information, Clinical record entries,
drug issue details, payment details prescription, registration information etc.
Table 2 – Instances of DFD elements in the example GP Practice system DFD
Report name: Model Development Guidance
29/09/2015
Use Cases
A use case describes a way in which a real-world actor interacts with the system. Use cases
allow to describe even a complex system in an easy to understand way, and tell in simple terms
what the system is going to do for its users. The most difficult aspect of developing a system is
the precise conceptualisation and specification of the system to be built. We suggest the use of
notation specified in the Unified Modelling Language (UML) (Figure 7).5 The simplistic nature
of UML use cases diagrams is useful to formulate a blueprint to understand the system,
requirements particularly when the domain information is acquired through multidisciplinary
teams having varying levels of technical aptitudes. We are also able to nest use cases at several
levels to decompose the large complex systems.
Elements of a use case
Actor: An entity that interacts with the system fot the purpose of completing an event.
Functional requirement: Use cases capture functional requirements that specify the
intended behaviour of the system.
Goals: Use cases are typically initiated by a user to fulfil goals describing the activities
and variants involved in attaining the goal.
Figure 7 – Symbols used in use case diagrams
Tools:
Microsoft Visio
https://www.draw.io/ (Web based)
UMLet (www.umlet.com)
Resources:
Report name: Model Development Guidance
29/09/2015
Use case diagrams http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
Art of writing use cases http://bit.ly/20tvu0I
Use case tutorial http://www.cragsystems.co.uk/use_case_tutorial/index.htm
Writing effective use cases http://bit.ly/1QGf7bC
Figure 8 – Use case example – Health care surveillance
Business Process Models
Business process models are graphical representations of business oriented processes within an
organisation. This is helpful to model collaborations and business transactions within health
systems.6 Business processes are typically modelled using the Business Process Modelling
Notation (BPMN). BPMN depicts the end to end flow of a business process. The notation has
been specifically designed to coordinate the sequence of processes and the messages that flow
between different process participants in a related set of business activities.7 The key elements
used in drawing BPNM diagrams are given in Figure 9. Several BPMN diagram examples are
given in Figures 10-11.
Report name: Model Development Guidance
29/09/2015
Figure 9 – Key elements in BPMN
Figure 10 – Simple example using BPMN
Figure 11 – BPMN diagram of a data acquisition process of a health research project8
Report name: Model Development Guidance
29/09/2015
Tools:
Microsoft Visio
https://www.draw.io/ (Web based)
Resources
Business Process Modeling Notation(short introduction)
https://www.youtube.com/watch?v=1RbKa6Z12fQ
BPMN Quick Guide http://www.bpmnquickguide.com/#wiifm
BPMN diagrams http://ibm.co/1QcGOWR
References 1 Checkland, Peter. "Systems thinking, systems practice." (1981). 2 Checkland, P. (2000), Soft systems methodology: a thirty year retrospective. Syst. Res., 17: S11–S58. 3 Monk A, Howard S. The rich picture: a tool for reasoning about work context Interactions, 5 (2) (1998), pp. 21–30. 4 Bruza, P. D., Van der Weide, Th. P., "The Semantics of Data Flow Diagrams", University of Nijmegen, 1993 5 Rumbaugh J, Jacobson I, Booch G. "The unified modeling language reference manual." 1999 6 de Lusignan S, Krause P, Michalakidis G, Vicente MT, Thompson S, McGilchrist M, Sullivan F, van Royen P, Agreus L, Desombre T, Taweel A, Delaney B. Business Process Modelling is an Essential Part of a Requirements Analysis. Contribution of EFMI Primary Care Working Group. Yearb Med Inform. 2012;7:34-43. 7 Bpmnorg. 1. Bpmnorg. [Online]. Available from: http://www.bpmn.org/ [Accessed 3 February 2016]. 8 de Lusignan S, Cashman J, Poh N, Michalakidis G, Mason A, Desombre T, Krause P. Conducting requirements analyses for research using routinely collected health data: a model driven approach. Stud Health Technol Inform. 2012;180:1105-7.