cobis data 13/11/2009. progress j kinsella anaesthesia pain and critical care burns smoke inhalation...

Post on 02-Jan-2016

216 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

TRANSCRIPT

COBISData

13/11/2009

Progress

J Kinsella

J Kinsella

Anaesthesia Pain and Critical CareBurns

Smoke inhalationBurn Pain

SICS audit GroupDatabase research (ACHE ACCERT)

Scottish Intercollegiate Guideline Network

Data

Janet BaxterElizabeth Bream

Martin ShawCharlotte Gilhooly

Data subgroupCOBIS members

Progress

• Starting point– Some data– Unreliable– Double counting – Inconsistent– Barrier to progress, audit and research

– No joined up working

Progress

• Initial data collection– Good picture– No use for assessing progress, trends etc

Challenges

• Lack of expertise• Busy• Individual goals• Lack of expertise

• Central records systems• NHS firewalls• Caldicott guardians

Opportunities

• Experience

• Good will

• Expertise found

Progress

• Dataset agreed

• Dataset refined

• Data collection system developed

• Challenges overcome

Data collection system

• Complete

• Demonstrated today

• Ready to go live 01/01/10

Burns Audit System

• System needed to be:– Scalable– Reliable– Secure

• Web application– All components are Microsoft derived as this

is the preferred platform of the NHS.

System Overview

Local server

Local client

Firewall

Central Repository

Local Systems

• Local Server– Hosting the web server application– Hosting the database server– File transmission software to central server

• Local client computers– No configuration required all should have a

web browser already

Central Repository

• Server– Hosting the main audit database– Software for receiving files form remote

computers– Reporting tool of some description

• Location– Glasgow, for ease of maintenance and

support

Software Overview

• This can be easily summarised in two parts:– The Information Schema– Initial views of the web application frontend

Information Schema

Information Schema

Information Schema

• Blue: Demographics

• Red: Admitted Cases

• Green: Referred Cases

• Gray: System Audit– Change tracking.

Information Schema

• Patient Journey– Heart of the system– All actions carried out on the patient listed

sequentially here.

Visit demonstrations

• To give an idea of what the system will generally look like:– Login– Main Screen– Patient Information– Case Edit– Injury List– Burns Bundles

Frontend: Logon

Frontend: Main Screen

Admitted and Referred

• These are separate for two reasons– The main aim of the system is only to collect the

severe burns admitted to the units– Security

• Its possible to have referral editing rights without having admitting rights.

• Allowing A & E’s to use the referral section minimising workload of burns unit staff.

• They contain virtually the same information– So views of one will be similar to views of the

other

Frontend: Patient Information

• One way hashes– Essentially a function that can be evaluated in

one direction only and cant be reversed to obtain the original result.

– OneWayFn(CHI) = HashValue– SHA hash designed to military and

government encryption standards– The central repository will match on this

anonymous hash value

Frontend: Case Edit

Frontend: Injury List

Frontend Burns Bundles

Problems remaining

• Staffing

• Computer systems in each centre

Proposed

• Minimum dataset from 01/01/10– If no computer still collect data– Local reporting…local audit– National reporting minimum one per yr

• Trends• Overall picture• Infrom future practice research and audit

What it is not

• A fully electronic case record

• A comprehensive list of everything you can imagine

• Unusable

Questions

• Purpose?– Local and national

• Reporting frequency– For discussion – annual

• Effort required– Piloted

• System failure

• Confidentiality

top related