Making IT work - Problem Child


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Good afternoon Ladies and gentleman for those who do not know me my name is Tom Faichen, I am employed as the Laboratory IT Manager at Monklands and Hairmyres Hospitals. In a previous talk I asked the question is IT the way forward and I guess I must have convinced someone as today I have been asked to talk on Making IT work.
  • I intend to start with a bit of background information about myself in order to give you a picture of where I am coming from. I felt it would then be useful to define what way and my reasons for how IT should now be taken forward still with the laboratory perspective but now thinking in our role in the NHS as a whole. Before describing how I would make IT work using OCS as a key requirement.
  • I would just like to put these points up about myself as I believe some of them will come through in my talk. Bullets in order Those of you who know me may add some others but I would rather you kept them to yourself.
  • 1 I do not know if I like to admit it but like a growing number of us I have been around labs a fair time.
    2 Most of my career has been very specialized working in Bellshill Maternity.
    3 Around 1985 I was given the task of evaluating, procuring and implementing a Stand alone Blood Transfusion system which had a very dramatic effect on the Department, rid of filing cards, writing reports etc. This sparked my interest in Computing, I was also conscious of the difficulty I would have getting promotion and felt I needed another string to my bow, I therefore undertook a degree in IT related subjects through OU and currently I have just completed the last module of a Post Grad. Diploma in Health Informatics with the RCS(Ed).
  • The government policy in reforming the NHS is dependant on the use of IT as the backbone of the NHS. The efficient treatment of patients is now more than ever dependant on the movement of vast quantities of data most of which is supplied by either Laboratories or Radiology. In the labs we have seen how automation and IT allowed us to supply that data but we now have to look beyond the labs to see where better use can be made of technology. IT in the Laboratories is in the main working well and accepted indeed valued by its users and yes although we still require development in areas such as Lab to Lab Links it is essential that the more important step is the manner in which we receive and report patient data.
  • The ultimate goal of these reforms is to get the data from the service departments i.e. medical records, Labs, radiology, pharmacy etc into a single record that health care professionals involved in the care of the patient can appropriately access when they require it. This will aid patient safety, allow decision support and help create more efficient use of scarce resource. Indeed it is now possible to have context sensitive links to both local and national guidelines for clinicians to easily keep up to date in what is current best practice.
  • For these goals to succeed it is essential that the future in laboratory computing is not within the lab but how our systems are connected to the rest of the organisation I would suggest therefore that the Order Communication Systems will be how we make IT work.
    In a patient centred NHS, technology must be used to aid patient safety and journey through the NHS. This could be with the use of bar-coded ID wristbands for example while waiting on Radiofrequency Identification to become available. Allowing in the case of blood transfusion vein to vein positive identification with full audit available. Indeed had these systems been in place compliance with new EU Blood Directive this month would have been more easily achieved.
    At a recent conference at the RCS(Ed) Dr Andrew Steele suggested that in the USA medical error due to misidentification or inappropriate testing etc killed the equivalent of an Aeroplane crash daily. Mr Paul Whatling (past chairman NPfIT) suggested in England and Wales it was 2 plane crashes a week.
    This may be a highly emotive way of describing the problem but if the figures are indeed in this region then it is essential they are reduced for both the patient and the organisations needs. Indeed death by NHS errors was highlighted on National News only last Thursday and therefore the political urgency for this issue to be addressed will be compounded by media attention.
  • 1 I would suggest that one the most important use of OCS will be allowing the Laboratory some control over demand with protocol based ordering using .
    2 Using electronic ordering or database enquiries will allow us to gather evidence of unnecessary testing and by presenting the information at the correct time stop unnecessary bleeding of patients.
    3 It will also reduce errors, allow better patient validation and a reduction in transcription errors by electronic reporting instead of phone calls.
  • 1 With electronic ordering the Laboratory staff can agree with Clinicians/GPs protocols defining tests required when and how often e.g. Chest Pain screen, Abdominal Pain Screen and so on thus hopefully removing tick box syndrome.
    2 These can be amended and updated based on current Clinical Guidelines and Evidence Based Medicine. If EBM or clinical guidelines suggest new screening tests then laboratory staff working with Clinical staff are aware of these before testing commences and can secure appropriate funding. These screening programmes in the past have been accepted as Fait Accompli by the labs.
    3 There can also be control of expensive tests and tests such as HIV where patient counselling is required by ensuring authorisation of the test at consultant level.
    4 I would suggest these systems will automatically refer requestor to the patient record if a repeat test is being asked for thus reducing unnecessary duplication.
  • However if these systems are to work we must remember that IT is only part of the solution.
    How we implement and use I.T. must be considered
    Think about turning Data into useful information then knowledge. Think as a patient and how you would expect your information to be used. As a patient I expect my information to be treated with confidentiality in mind but that anyone who required relevant information in order to treat me correctly must be able to access it.
    If my safety is enhanced by the local NHS organisations having access to my demographics then they should have that access and I will return to this point later.
  • The last module of my Informatics course involved researching implementations of OCS and I discovered that this aspect plays a major role in successful implementations.
    I have added some of these references on my last slide but they suggest that the implementation will involve both development of the ‘technical’ system and the ‘users’ working practices to get the best ‘fit’ and a successful implementation. Therefore involvement of key staff to act as champions as well as reviewing working practice will be essential. It was also suggested that the vendor experience in the way the organisation operates will be of value when implementing an ‘off the shelf’ solution and perhaps explains the number of adverts from the major IT companies wanting NHS Staff.
    Key staff that must include Clinicians and other Health Care Professional’s on whom the system success will depend. The problem being that this staff group is the hardest to get on board due to pressure of work but they are essential. These key staff then provide a communication channel to their own departments and may take on a cascade training role as the implementation proceeds. Indeed these staff may require to be seconded from their own posts for a significant period of time.
  • OK I now would like to go over some of the problems I feel have to be overcome.
  • 1 I believe this is fundamental to a safe OCS and ultimately EPR/EHR and this will be hardest to solve and is the cause of most pain as we bring systems together. And although others have spoken today about this I felt I must reemphasise the importance and give a possible solution to consider when joining up disparate systems. In Lanarkshire we have a patient number for each acute hospital, there were 5, as well as Primary care, GP systems and of course CHI. Indeed 1 of the hospital numbers format is identical to CHI. The task of merging these records into 1 CHI number cannot be understated. I would imagine that this is the case almost everywhere. It is worth discussing this point some more and I will suggest a radical solution – Start Again.
  • I feel this solution is the safest and best way of moving on from these historical problems. Other solutions such as multiple indexes cannot address the problems of the errors in the historical data created by manual entry and then automated links.
    I believe that the majority of patients would not object to their demographic details being available at point of contact with the NHS and therefore there is no reason e.g. that Lanarkshire NHS CHI demographics are not downloaded into the Patient Administration System updated then fed to the service systems. An opt out policy can be created where a patient registering with a GP can opt not to share their data as is their right under the DPA. It can be explained at this point why it is important that they are positively identified on presentation. This I feel is the only way that areas such as A&E can be assured that 95% or more of patients presenting are on the database and therefore reducing duplicate entries due to spelling or other errors.
    I also would suggest that it is therefore essential to start again on the service databases such as Labs and Radiology. A lookup account of historical laboratory data is sufficient for most departments preferably linked to a single login to the main system for lab staff.
    Where necessary again for example in blood transfusion this data can be merged into the new record on presentation and after ensuring that it is the correct patient.
    I do feel that there is more clinical risk associated with downloading ‘dirty’ data than not downloading it but I know there are a variety of views on this which if you wish we may discuss later.
  • This diagram if you can make it out shows the process as I (not a medical records professional) envisage cleaning the databases. There is an arrow missing showing that the new database updates the local SCI store. Don’t take notes Alistair I will give you a copy. Anyway, I can talk about patient Identification as those who know me until the cows come home and while paramount there is a lot more to be done to make IT work
  • One of the biggest issues will be staff fears of change. These fears are that systems will be more difficult to use, result in loss of power base, loss of jobs, its not my job etc. I remember the problems trying to bring our departments together Biochemistry and Haematology sharing the same system! Now our problem is extending this across all disciplines in the organisation.
    Obviously no system will provide perfect functionality for all users but discussion and development should be able to get the best solution if we try and understand other user needs rather than only our own. Minor inconvenience to 1 department initially could provide major functionality to another.
  • The aspect of Confidentiality is probably one of the most difficult to get round as systems combine.
    1 The data must be secure and staff should only be
    2 able to view on a need to know basis appropriate to their role.
    3 There must be accurate audit trails of all data access. Getting the balance of appropriate sharing versus restricting access is difficult. My personal belief is that most patients like myself will not object to appropriate sharing of healthcare data. I include in this use for research purposes as well as direct patient care.
    4 However as some patients will object to this anonymised data must be used where possible for R&D
    My reason for mentioning this as a problem is the resource implication of password maintenance and audit is substantial. This is an even larger
    problem currently where access to multiple unconnected systems is required such as ward users enquiring directly on separate Lab, Radiology etc systems. There is also a need to get a fast secure login for individual users using for example a card that automatically logs them out of all systems on removal.
  • 1 Great play has been made of the extra money being put into IT however in the past this resource was not ring fenced and tended to be used for other purposes. The systems now envisaged also require 24/7 cover therefore there has to be sufficient resource to provide this support either in house or by contracting out. An other problem that has occurred up to now is that when a system is implemented it is then allowed to run for considerable periods without upgrading ancillary hardware. Regular replacement programmes for PC’s, printers etc attached to main systems must be included in support budgets.
    2 Using old equipment or replacing equipment as a fire fighting exercise results in staff stress and disenchantment and can lead to system failure.
  • A number of quality issues come to my mind as problems. As the disparate systems join so we find that although standards such as HL7 are used for messaging the implementation varies between different suppliers due to differences in for example database structure e.g use/non use of middle name field. This may result in messages being received differently across different systems. Users vary in how data is entered and this may cause problems in other systems as data is passed between them. After system upgrades older problems reappear functionality changes unexpectedly.
    A Recent paper presented on the Laboratory Special Interest group on the Health Informatics site suggests the lab is losing control of their reports as electronic messages are broken up and recombined in the format required by the receiving system. This presents us as data suppliers with the problem of how do we quality control these issues when so many systems are now joining up. An important part of making IT work as we do not want to replace the patient safety problems with new system patient safety issues.
  • I would now like to make a few points about what I feel is the most important needs for successful implementation.
  • For a successful implementation it is essential that staff receive adequate training and this is an area that is perhaps not sufficiently invested in partially through financial restrictions but also in the available time to train staff. These points must be included -
    1 a basic overview of the importance of their part in the overall system. It is essential that users realise where the data they are entering ends up being used. If there is single point demographics being entered the staff responsible must realise that the data they are entering will be used by all systems interfaced and realise the importance of getting it right.
    2 There should be no excuse for not allocating time for training. I say should here because I have recently experienced the stress caused by inadequate training in my own implementation and hope I have learned from this.
    3 All systems have downtime either through failure or for upgrades staff must have regular refresher training both in current functionality and backup procedures.
    4 Training must be appropriate geared to an individual’s needs assessment,
    5 there is no point in training someone in Software they will never use or training 6 months before they will use the software.
  • Pilot site must cover as many aspects of the system that will be used, if a multi site and department system then the pilots should include as much functionality as possible. It would worry me if key decisions made to development of one area of the system caused problems in the roll out to another because of different working practices. However in the real world in major projects such as these it is not possible to cover everything. It may be worth before choosing pilot sites that a shadowing exercise is undertaken to map workflow and highlight where problem areas may occur for example moving data entry from clerical personnel to clinical personnel in an unexpected manner (ref ). It is important for the success of these projects that the task being taken over by the ‘system’ is at best as easy to perform or easier or ‘users’ will ensure the system fails (ref ).
  • It is essential for future projects that implementations are reviewed and monitored to provide evidence of the success or otherwise of the project. If we are to make these systems work then we must convince ‘users’ i.e. clinicians and other HCP’s that they are of value and currently while there is plenty of anecdotal evidence I found it very hard to find published details of Return on Investment and proof that the efficiency savings envisaged were achieved. This is partly because these large projects are implemented over considerable time frames and really ROI cannot be truly seen until the last piece of the jigsaw is in place. I still think it essential, however, that both positive and negative findings are published. Recently for example I was being interviewed by a CPA inspector and during discussion on OCS he told me that rather than a reduction in testing his workload had increased by more than 10%.
    I would suggest therefore that prior to pilot sites going live audit of a number of measurements which can confirm that these systems do indeed give the expected return on investment in Patient safety and reduction in unnecessary testing.
  • In summary then this is how I see we can make IT work --- Bullet points ----
    I hope the talk has succeeded in at least making you think about how we use IT to fulfil or ambitions and that if you have any points to make we get time in the forum for some discussion. Thank you for your attention.
  • I have included a few of my references that I found while researching this subject for my final module. Anyone who wishes a copy of my talk I believe we will be making them available on the internet but please email me and I will send you a copy.
    Thank you for inviting me and I hope you found my talk informative and thought provoking and hope there will be some discussion later.
  • Making IT work - Problem Child

    1. 1. 1 Making IT WorkMaking IT Work Tom Faichen BSc CSci FIBMS BMS 3 (Lab. IT Manager)
    2. 2. 2 TopicsTopics Personal Background. Why IT is necessary What we want IT to do now How to make IT work
    3. 3. 3 Personal QualitiesPersonal Qualities Idealist A bit Naïve at times Like playing devil’s advocate Most importantly I am fully aware that as well as an employee of the NHS, I am also a PATIENT !!
    4. 4. 4 Personal BackgroundPersonal Background 35 years in Laboratory Medicine Most specialising in Maternity/Neonatal Haematology and Blood Transfusion Became involved in Lab Computer Systems 1985 Have played a major role in procurement, implementation and management of 4 LIMS
    5. 5. 5 IT Development - WhyIT Development - Why Government Policy of reform in NHS Patient centred Policy with IT backbone Patients demand fast efficient NHS Providers dependant on efficient data transfer and presentation Labs and Radiology supply 60-70% of patient data
    6. 6. 6 Electronic Patient/HealthElectronic Patient/Health RecordRecord The driving force of these reforms Getting all the data into a single patient record Aid Patient Safety Allow Decision Support - allow links to Guidelines and EBM Aid efficiencies and use of scarce resources
    7. 7. 7 Order CommunicationOrder Communication SystemsSystems  Patient Safety – Positive Patient Identification (Bar Coded wristbands/RDIF) – Vein to Vein tracking when issuing blood products – Printing of labels at point of collection  Electronic Transmission of order to Lab.  Electronic tracking of order back to patient
    8. 8. 8 Laboratory Taking ControlLaboratory Taking Control Electronic/Protocol based ordering Single EPR across multi-site/sectors – Reduction in unnecessary duplicate testing – Use of Evidence Based Laboratory Medicine Transcription Error Reduction – Patient validation – Electronic reporting – Electronic links between Laboratories
    9. 9. 9 Electronic OrderingElectronic Ordering  Agreed Electronic Protocols – Chest pain, Abdominal pain  Guideline Awareness  Hierarchical control of expensive/sensitive tests – Consultant to authorise before test can be ordered  Duplicate Testing Control – Clinician automatically referred to previous results or outstanding request status
    10. 10. 10 HowHow I.T. is only part of the solution How we implement and use I.T. must be considered Think about turning Data into useful information then knowledge Think as a patient and how you would expect your information to be used
    11. 11. 11 Sociological and CulturalSociological and Cultural IssuesIssues Major change in working practice across the whole organisation Development of ‘technical’ system plus Development of ‘users’ working practices Gives ‘best fit’ and successful implementation Key staff must be involved from beginning of any project
    12. 12. 12 Problems to be overcome.
    13. 13. 13 Unique Patient IdentifierUnique Patient Identifier Fundamental to EPR/EHR Current Multiple Numbers held in Legacy systems across sites – Problems importing historical data – Problems keeping disparate records up to date – Problems Identifying patients to avoid multiple records
    14. 14. 14 START AGAIN
    15. 15. 15 Patient Database CleanupPatient Database Cleanup  Complete download all area patient demographics into new PMS Database  Link to local SCI Store and National CHI Database for updates  Merge matching historical records to new database on presentation  Populate all service systems such as Labs with new Database  Only download minimum historical data into new service database keep all rest in lookup account.
    16. 16. 16
    17. 17. 17 CommunicationCommunication Staff Fears – Communication between all disciplines/departments involved – understanding that there will be disadvantages as well as advantages to individual groups – Adequate training for all users
    18. 18. 18 ConfidentialityConfidentiality Patient Data must be secure Staff access on ‘need to know’ Appropriate audit trails on data access Include for use in R&D, EBM Resource Password maintenance Secure fast logins
    19. 19. 19 InfrastructureInfrastructure Investment in infrastructure must include – Ring Fenced finance – Sufficient support to provide 24/7/365 cover – Regular upgrading of supporting equipment Insufficient investment in above leads to – User stress, user disenchantment – Ultimately system failure.
    20. 20. 20 Quality IssuesQuality Issues  Variation in use of Standards – Database structure variations – User variation in data entry  Search methods  Use of case  System upgrades – Reintroduction of ‘bugs’ – Functionality changes  Applying Quality checks
    21. 21. 21 System Implementation and Post Implementation Review
    22. 22. 22 TrainingTraining Include overview of whole system Training time must be made available Refresher training especially in backup procedures Geared to individual needs assessment Appropriate training at appropriate time
    23. 23. 23 Pilot SitesPilot Sites – Must be representative  Include all sites if multi hospital  Broad spectrum to cover most eventualities  Where possible interface to all systems which will ultimately be connected – Must have eager Champion – Must realise there will be pain before gain – Should not be extended beyond pilot until all major issues are resolved
    24. 24. 24 System ReviewSystem Review  Pre and post pilot audit of – Length of stay in unit (e.g. ICU) – No of requests with complete dataset – No of duplicate tests – No of clinical incidents reported with patient ID problems  Publish Findings
    25. 25. 25 Summary for Making OCS WorkSummary for Making OCS Work  Strong strategic leadership from project board  Solve the Patient ID problem  Getting the correct system ’champions’ to lead their area of the project  Ensure full understanding of current work practices  Ensure new work practices are not slower than current  Ensure adequate training at the right time  Publish findings
    26. 26. 26 ReferencesReferences  1 Strategy for Information; NHS ScotlandStrategy for Information; NHS Scotland; Accessed 29/6/2005  2 National eHealth IM&T Strategy 2005-2008 ; NHS Scotland Accessed 30/6/05  3 Information Technology in Complex Health Services Organizational Impediments to Successful Technology Transfer and Diffusion; Frank Charles Gray Southon, MSc, PhD, MComm, Chris Sauer, PhD, and Christopher Noel Grant (Kit) Dampney, Msc, PhD; J Am Med Inform Assoc. 1997 Mar–Apr; 4(2): Accessed 2/7/05  4 Understanding Implementation: The Case of a Computerized Physician Order Entry System in a Large Dutch University Medical Center; Jos Aarts, MSc, Hans Doorewaard, PhD, and Marc Berg, MA, MD, PhD; American Medical Informatics Association, J Am Med Inform Assoc. 2004 May; Accessed 2/7/05  5 Lorenzi NM, Riley RT. Knowledge and change in health care organizations. Stud Health Technol Inform.2000; Accessed 2/7/05  6 A Consensus Statement on Considerations for a Successful CPOE Implementation; Joan S. Ash, PhD, MLS, P. Zoë Stavri, PhD, MLS, and Gilad J. Kuperman, MD, PhD; J Am Med Inform Assoc. 2003 May–Jun; 10(3): 229–234. Accessed 13/8/05  7 Computerized Clinical Decision Support: From the Classroom to the Patient’s Room –Presentation by 1st MSc graduate, Dr Andy Steele; Health Care Informatics Symposium; 28th June 2005 Royal College of Surgeons Edinburgh  8 The National Programme for IT: Safer Care for Patients – Dr Paul Whatling, Former Clinical Lead, NHS Connecting for Health;Health Care Informatics Symposium; 28th June 2005 Royal College of Surgeons Edinburgh  9 Reducing costs with computerised order entry Core Informational White Paper accessed 13/8/05  10 Medic to-Medic® and the Map of Medicine® – Dr Enone Honeyman; Health Care Informatics Symposium; 28th June 2005 Royal College of Surgeons Edinburgh