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.