Home int. Burn Injury Database iBID Design

iBID Design

int. Burn Injury Database (iBID)

Throughout the design and development process, from 1992 to the present day, a number of design principles have emerged. These have been derived from experience, sometimes painful, whilst others have been gleaned from the experience of others, again sometimes painful for them.

They are an amalgam which we suggest should be carefully considered by anyone proposing to create any form of clinical registry. They may not all apply, but there are simply offered as a brief guide and as a list of features that have acted as principles behind the development of the iBID software and analysis processes.

Overarching Principles

  • clinical tool from which service data is derived - designed for use to record the clinical process and not as a pure management tool, unlike many packages offered to health care.
  • define a minimum data set (MDS) to allow basic analysis - intended to place the patient in time and space with sufficient patient and injury definition information.
  • no absolute data requirements - no instances of data entry being frozen because a data item is not available and cannot be entered.
  • design process driven by users - both clinical and managerial users of the information have valid ideas and suggestions
  • add tools to versions as suggested by users - but do not expect them all to be used by everyone all the time. This makes the software larger but more versatile.
  • allow the whole care period to be followed- from injury to final discharge from a service.
  • include process and clinical outcome measures - and encourage the development of key performance indicators (KPI) that are clinically and organisationally meaningful.
  • iterative improvements in software and analysis should be as simple to enact as possible - minimal 'hard coding' of processes to maintain maximum flexibility.
  • minimise the cost of collection - usually by minimising the need for staff time and hardware requirements.
  • meet the information needs of the funders/commissioners of care services - otherwise collection will not be supported in the long term.
  • data provision linked to service designation and funding - helps ensure funding support and ensure data contribution.
  • verification process designed in parallel - in the UK NHS we have the HES system against which to compare the iBID data
  • design for multi language implementation - in iBID this was initially intended for the Welsh language but the design feature would allow any language to be accommodated.
  • modular design allows expansion - the incorporation of such features as telemedicine, injury mapping and image library, up to full EPR is therefore possible.

Software Principles

  • minimal infrastructure requirements - minimal OS, RAM and Internet connection requirements.
  • use existing global computer system design and data standards.
  • no licences or costs over the basic OS.
  • free software to user.
  • downloadable or delivery via USB stick as a single application - one package for all types of user.
  • use as a stand-alone or as a network application - maintain versatility.
  • does not require computer administration rights to load for use as a stand-alone database.
  • does not require firewall permissions to use the Internet connection.
  • multi platform front end - a principle that has, as yet, not been achieved for iBID.
  • multi platform from server point of view - tiered design allows multiple server types and software to be used by host organisations.
  • centrally update-able menus and calculations invisibly implemented via the Internet connection.
  • allow ODBC linkage locally - for additional data collection as required.
  • APP-able for smart phones or tablets - can be done but profound problems with data security and maintenance of confidentiality.

Data collection Principles

  • use simple methods to collect/enter data mostly drop down menus and tick boxes, which allows multiple staff to input data, as training is minimal.
  • avoid free text entry - as this adversely affects the time needed for input, data accuracy and meaningful analysis.
  • on screen help - updated via Internet, but also available offline by local storage and updating.
  • on screen error checking and data quality support - with the ability to override items that are not correctable or available.
  • maintain local service data control and ad hoc data exporting with local analysis using provided tools.
  • automatic, secure, near real time centralisation of data - maintaining confidentiality but allowing record identification for audit and data validation.
  • keep centralised data packages as small as possible - avoids problems with unstable Internet connections.

Reporting and Analysis Principles

  • maintain patient confidentiality throughout.
  • maintain service anonymity in reporting - until such time as this is not required.
  • reporting allows peer group comparison at various levels - regional, national, service designation level etc.
  • hands free analysis process to minimise staff time use centrally - makes the capacity of the system scale-able and expandable with little resource difference needed to analyse 30 services or 3000.
  • near real time data provision to dedicated website(s).
  • website(s) maintain standard reports updated daily - including data provision, quality (errors) and record completion.
  • linkage of reporting to iBCS requirements - in terms of service activity / injury severity spectrum / outcomes.
  • linkage of capacity usage to NBBB - providing near real-time information about bed availability routinely and for a Major Incident response.
  • website(s) allow mapping, searching and export of data - within the limits of the requirements to maintain confidentiality.
  • ad hoc data access controlled by a governance process - for complex or sensitive requests or those requiring significant resources to perform.