Doing It with Nodes Design Patterns in Healthcare Education Standards and Specifications Rachel Ellaway, PhD The University of Edinburgh and The Northern.

Doing It with NodesDesign Patterns in Healthcare Education

Standards and Specifications

Rachel Ellaway, PhDThe University of Edinburgh and

The Northern Ontario School of Medicine

design patterns

A general repeatable solution to a commonly occurring problem in software design.

However, a design pattern is not a finished design that can be transformed directly into code …

… it is a description or template for how to solve a problem that can be used in many different situations

S&S context education informatics …

Wikipedia

‘nodes’ (n) [latin nodus=knot]

A knot, a knob, a protuberance; a knotty formation

A knot or complication; an entanglement

A point at which branches divide

A point of significance; a crux, a critical turning point; a focal point

A junction; a point of intersection or convergence

A point or line of absolute or comparative rest in a standing wave system

Tube map © Transport for London 2005

nodes: cyclic and acyclic graphs

graph theory

arrays of vertices (nodes) and edges (links)

cyclic = bidirectional edges

acyclic = unidirectional edges

V: = {1,2,3,4,5,6}

E: = {{1,2},{1,3},{1,4},{2,1},{3,4},{4,5},{4,6},{5,3}}

nodes: db

ID data

1 xq

2 vf

3 wr

4 gh

5 sg

6 ju

ID1 ID2

1 2

1 3

1 4

2 1

3 4

4 5

4 6

5 3

NODE

NODE_NODE

nodes: xml <nodes> <node id=“1”>xq</node> <node id=“2”>vf</node> <node id=“3”>wr</node> <node id=“4”>gh</node> <node id=“5”>sg</node> <node id=“6”>gu</node></nodes><links> <link id1=“1” id2=“2”> <link id1=“1” id2=“3”> <link id1=“1” id2=“4”> <link id1=“2” id2=“1”> <link id1=“3” id2=“4”> <link id1=“4” id2=“5”> <link id1=“4” id2=“6”> <link id1=“5” id2=“3”></links>

<?xml version = "1.0" encoding = "UTF-8"?>

<nodes></nodes><nodes> <node id=“1”>xq</node> <node id=“2”>vf</node> <node id=“3”>wr</node> <node id=“4”>gh</node> <node id=“5”>sg</node> <node id=“6”>gu</node></nodes><links></links>

<nodes> <node id=“1”>xq</node> <node id=“2”>vf</node> <node id=“3”>wr</node> <node id=“4”>gh</node> <node id=“5”>sg</node> <node id=“6”>gu</node></nodes>

nodes and learning tech (in auld reekie)

Trees, webs, networks, algorithms, mazes, games

Content management

Curriculum mapping

Wikis

Knowledgebases

Virtual patients

Pair up unique node IDs of different node sets to create matrices and mashups - SOAs

nodes and standards: MedBiquitous Virtual Patient

Virtual Patient Data (VPD) - data content (includes structural node trees)

Data Availability Model (DAM) - collections of VPD and media elements - DAMnodes within DAMnodes and DAMNodes attached to ActivityNodes

Activity Model (AM) - topology/browse expressed as node trees

S&S design patterns?

design patterns

A general repeatable solution to a commonly occurring problem in software design.

However, a design pattern is not a finished design that can be transformed directly into code …

… it is a description or template for how to solve a problem that can be used in many different situations Wikipedia

#1 ‘nodes’

Matrix combinations of different node systems

Highly abstract

Simple to model

Widely applicable

Principle 1: relational and procedural structures should be modeled using nodal frameworks

#2 ‘semantics’

Vocabulary/classification/annotation

Rather than named structures (tightly coupled) use generic structures with descriptors (loosely coupled) eg VPData in MedBiq VP

Also profiles of generic specs (healthcare LOM) - Communities of practice vs networks of practice

Principle 2: make the specific more generic accommodating the specificity using semantic markup

#3 ‘primitives’

Parent-child, classes/libraries, OOP relationships

Primitives as abstract/generic objects

Instances of primitives become more specific

Assemble to create complex, non-predetermined structures (cf Lego®, mashups)

Principle 3: simple structures can be instantiated and aggregated in different ways to create more complex structures (eg node matrices)

#4 ‘IDs’

Primary keys, GUIDs, addresses

Scope: local vs globally unique

Ability to target specific elements or collections

Semantic content: RHE_P2_APR18_MDBQ2007

Principle 4: elements and collections should be uniquely addressable using resolvable unique IDs

#5 ‘services’

Functions in/out of scope

Coupling - loose vs tight

Service oriented architectures (SOAs)

Component models - see IMSLD and LAMS

Principle 5: non-dependent and outside-scope functions can be cast as abstract (black box) services

#6 ‘state’

Static vs dynamic phenomena

Dependence on previous states or independent

Single or multiple state traces

Quantitative: analog or discrete valuesQualitative: semantics and annotations

Principle 6: recognize stateless and state-dependent phenomena and model each appropriately

#7 ‘formality’

Informal systems are an essential part of education

Formality is related to abstraction

Informal systems can be modeled formally using higher levels of abstraction (e.g. cartography)

Principle 7: distinguish between formal and non-formal systems and increase abstraction in the latter to render them more formally

?Design patterns for S&S

nodes

semantics

primitives

IDs

services

state

formality

Universal Principles of DesignLidwell, Holden and Butler, 2003

The Laws of SimplicityMaeda, 2006

Design patterns for S&S

General repeatable solutions to a commonly occurring problem in standards and specifications design

A standards and specifications design pattern is not a finished design that can be directly inserted into a schema …

… it is a description or template for how to solve a problem that can be used in many different situations

Developing ‘education informatics’

Doing It with NodesDesign Patterns in Healthcare Education

Standards and Specifications

Rachel Ellaway, PhDThe University of Edinburgh and

The Northern Ontario School of Medicine