What IBID Might Look Like

1. What IBID Might Look Like Dr Matthew Thomas Technical Consultant, Informatics

2. IBID Lessons from CoSurv New Requirements New Technology • What IBID Might Look Like

3. What “IBID” Might Look Like >> Lessons from CoSurv, IBID’s response What “IBID” Might Look Like >> CoSurv

4. Lessons from CoSurv What “IBID” Might Look Like >> Lessons from CoSurv, IBID’s response • it provides a common system across all partners and regions – which has been a huge aid to co-operation and multi-agency partnership working. We all use the same system and understand the data in the same way. • Networkable, allowing multi-user access which can be particularly important in outbreak circumstances • Encrypted email system for distribution of data ensures security and confidentiality • Basic data entry process is simple and user friendly (i.e. entering new cases from e.g. GP notifications) • By and large a stable system that does the job it's designed to do, if a little bit dated now • it provides a common system across all partners and regions – which has been a huge aid to co-operation and multi-agency partnership working. We all use the same system and understand the data in the same way. • Networkable, allowing multi-user access which can be particularly important in outbreak circumstances • Encrypted email system for distribution of data ensures security and confidentiality • Basic data entry process is simple and user friendly(i.e. entering new cases from e.g. GP notifications) • By and large a stable system that does the job it's designed to do, if a little bit dated now What “IBID” Might Look Like >> CoSurv

5. Lessons from CoSurv What “IBID” Might Look Like >> Lessons from CoSurv, IBID’s response Report retrieval is laborious & unreliable: Fields are overwritten with blanks; duplicates are created • The lab report and district report retrieval and update systems are not absolutely foolproof - in the sense that lab reports have to be retrieved and completed, but then there isn't an option within that process to print case reports for inclusion in an investigation file - this means that we have to manually note down all the names of incoming reports, and then browse the data individually for each one to actually print a report. Retrieval of District reports doesn't always work perfectly - we often find that incoming reports with blank fields can sometimes overwrite existing data (for example Locality which we use to record the electoral ward of the case). Also not incoming reports match up with an existing record, so we get occasional duplication of records. We have found a workaround for this (basically 'intercepting' the unencrypted text file before it is actually imported into the database, so that we can check its contents and then go through the incoming and updated records to ensure that any errors or duplication are corrected) - but it is a longwinded and cumbersome process. • Although Cosurv holds the key information for notification purposes, the section for Investigation is pretty limited, and the general comments text field is not very large either. It limits Cosurv's usefulness as a case management tool, which for some authorities has led to the use of parallel systems for case management, double data entry etc. • The District Reports analysis system is effective in what it does, but limiting in the sense that it doesn't seem to be possible to create 'custom' reports, which limits the capability as for any detailed analysis or surveillance it is often necessary to export the data to Epi-Info - and many EHOs are not very familiar with the use of Epi-Info (we are looking at training options to resolve this). • The distributed nature of the system means that local authorities are very reliant on CDSC for technical support when things go wrong (or if PCs are renewed then simple reinstallation) • Where updated notifications are provided from the lab (e.g. follow-up samples) there is confusion as to whether they should be entered as ‘updated episodes’, thereby losing the original sample information (specimen date etc) and possibly causing data integrity problems with the notification date (which cannot be earlier than the report date); or as ‘new episodes’ when clearly they are part of the same episode. It would be useful both for data integrity and case management purposes if it were possible to relate more than one laboratory notification to the same episode/patient. Insufficient fields for case management Can’t create custom analysis reports Highly reliant on technical support Issues with episode identification What “IBID” Might Look Like >> Reasons for Change

6. New Features Requested What “IBID” Might Look Like >> Lessons from CoSurv, IBID’s response Better interaction with outbreak management systems • In large outbreaks there is often a need to enter large numbers of cases who may not have been through the lab notification system (or via a system in another part of Wales or the UK) - if possible it would be useful to be able to import this kind of data from Excel/Epi Info etc to minimise the need for double data entry. Alternatively it may even be possible to design the new system in such a way that outbreak information can be stored or linked to it somehow. • Inevitably there are instances where cases are initially reported by the labs to the wrong local authority – it would be useful if authorities had the capability to 'reassign' cases to the appropriate authority so that they appear in the relevant listings. It would also be useful if postcode data (where available) could be linked to an Address Point type system to assist with the assignment of cases to the appropriate districts • Local authorities have experience in dealing with web-based notification systems via the accident reporting system for health and safety in the workplace - there will almost certainly be lessons that can be learned from that experience. As an example, that system relies on local authorities checking the system for updates on a regular basis - potentially meaning that accidents could lie un-investigated for a period if no-one remembered to check. This could be overcome by having some form of daily email update system, whereby authorities receive an email if there are specific cases that have been 'unread' - obviously the exact details of this could be looked at in the future. • To assist measurement of historical trends, some form of backward compatibility in data structure would be beneficial (but appreciate that it may not be possible to do this and meet other intended objectives) Re-assign cases; postcode completion Daily reminders of outstanding actions Enable analysis with historical data What “IBID” Might Look Like >> Reasons for Change

7. What “IBID” Might Look Like >> Reasons for Change

8. What “IBID” Might Look Like >> New Architecture INTRANET All-WalesLaboratory Information Management System Data Library (CDSC) All-WalesLaboratory DataStore IBID LabExpert

9. Architectural Benefits • Timeliness • Reduced Effort • Data Quality • Resilience • Extensibility • Supportability • Bug fixes • Upgrades e.g. look & feel • What “IBID” Might Look Like >> New Architecture

10. New Look & Feel • Web Interface • R&D • Example Informatics Solution • Neonate Immunisation Database What “IBID” Might Look Like

12. LIKE • Form Follows Functionality • Clear and simple navigation • not too many types of navigation • not too many places to go • Speaks for itself (intuitive) • Clear visual indication of current location (visual menu with links to other locations) • Data summaries e.g. Patient panel • “My page” concept with most important information/actions (dashboard) • Feedback: progress bars and location; feedback we are logged on as ourselves and when we last logged on • Boundaries around discrete sections • hover-tips (unnecessary for frequent users – don’t justify the work involved?) • Logo in top-left of screen (with link to PHW home page) • Field labels above text boxes • Tabbed sections – with a change of colour for the currently selected tab • Use of drop-downs for data entry (quicker and automatically validated) • Responsive sites • Pop-ups for completion of details • Background colours that do a good job of lifting the key screen areas DISLIKE: right-align text labels, too much on one screen, icons with unclear meaning, too many icons, small text or small icons, excessive white space on pages, excessive space between labels and fields, too many ways and places to navigate, colour combinations which result in low contrast for data Cluttered screens (e.g. 3 lots of tabs – how is the data in each related?), bold field labels, garish or excessive colouring, getting lost (poor navigational feedback), low contrast data fields, menus along the top

13. Best practice • Usability Gurus • http://www.useit.com/papers/heuristic/heuristic_list.html • Examples • http://designingwebinterfaces.com/6-tips-for-a-great-flex-ux-part-5 • Technical • http://www.bbc.co.uk/guidelines/futuremedia/accessibility/ • http://webaim.org/techniques/javascript/ • Accessibility Guidelines • http://www.webcredible.co.uk/user-friendly-resources/white-papers/web-accessibility-guide.pdf • http://www.w3communications.co.uk/AccessibilityGuide.asp What “IBID” Might Look Like >> New Look & Feel

14. Example Informatics Solution What “IBID” Might Look Like >> New Look & Feel

15. Happy Retirement CoSurv! AFTER LUNCH: “Using IBID”, by Chris Ollier Panel Discussion IBIDSupport@wales.nhs.uk • What IBID Might Look Like