 Good afternoon ladies and gentlemen. Welcome to this lecture on electronic medical record implementation considerations. My name is Yashik Singh and I am from the Department of Telehealth at the Nelson R. Mandela School of Medicine. In this lecture, we're going to try and give you an idea of how you would assess the value of a medical informatic solution. In fact, in this case specifically an electronic medical record. We want to actually make you aware of some of the questions that you need to ask before you roll out any type of electronic medical record. And share with you some points that will help ensure the successful implementation of electronic medical records and medical informatic solutions in general. We all know that information systems are actually required to manage medical information and it has been proven that these are actually beneficial. But three quarters of all information systems fail. One example of this is actually in Lopopo which is a province in South Africa. Although the Lopopo government spent 134 million South African rands and called IBM who is very very well respected in developing innovative technologies. The system still failed. So the question that you probably would want to ask yourself now is why do these electronic medical record systems actually fail. Even though so much of money has been used and such experts have been called to actually design the systems. And this is basically what the lecture is going to try and answer and also show you how you can prevent this from happening. So why do electronic medical record systems fail. One of the main reasons is poor communication. The communication between IT guys and clinicians are notoriously terrible. They may be saying the same words but they are thinking of completely different things. So communication between clinicians and computer scientists or information technologists has to be improved. And that is why this training in medical informatics is actually so important. Medical informaticians will now sit at the bridge between medical staff and computer scientists. And computer scientists in fact the medical informaticians will be able to design these systems themselves. And because they will be able to better communicate with clinical staff the systems should actually be much better and more efficient. Another reason why EMR systems fail is because the developers are unaware of the environment in which they are actually developing the technology for. In the example that we spoke about in the POPO a baker sitting on a grid caused the electronic medical record or the hospital information system to continuously fail. And if you were not from a developing country you would have not realized that this could actually have been a problem. You would not realize that infrastructure is actually a terrible, terrible problem in developing countries. So the developer the person that is developing the system must be aware of the clinical environment that he is actually putting the systems in. The major reason why electronic medical record systems fail is because there have been no change management put into place. Ensuring the success of an electronic medical record is more than just developing a system and installing it. That's only one part of medical informatics. It's only one part of ensuring the success of an electronic medical record. You have to make sure that proper change management is in place. You have to make sure that people are guided into using the system. Are we going to speak more about this in this presentation? Perceptions. They are resistance to change because of ill perceived perceptions on both clinical staff's point of view as well as the other admin and research staff that I will actually use these systems. In previous lectures we spoke about security perceptions. We spoke about how people instinctively feel that by putting medical data onto a computer you are in fact making it less secure than what it in fact is right now. There is no support from government. Of course government cannot be blamed for this if you are in a developing country and if you have limited resources and you have a large percentage of people dying from HIV and require ARVs. There has to be a good plan put in place to actually convince government to spend money on electronic medical records. Another big reason why there is failure is because there is just too high expectations from clinicians. They feel that the first time they get an electronic medical record it will be full of wonderful tools that will just make their life completely simple without realizing that there has to be phased in. The tools must be phased in. So they have a very high expectation when they see the basic system they get disappointed and of course their interest wanes. When you are thinking about essential considerations for an electronic medical record you should think about the following. Think about the needs assessment. Think about the design and testing of the system. Think about things that deal with the implementation of the system. And importantly think about the functionality of the system. And we are going to go through each one of these. Needs assessment. Needs assessment is probably the most important part of ensuring the success of your system. Of ensuring that you actually develop or implement a worthwhile solution. It directly affects the success or failure of your electronic medical record. And the reason again for this is communication. You need to tell the computer scientist or the person developing your system what you need. And this communication is very very important. It is important to realize also that high end and sophisticated technology is not always the correct solution. Because something is sophisticated because it advanced doesn't mean that it is the correct solution for your problem. So don't look for a nail once you have a hammer. The solution that you create needs to be simple. It needs to be the simplest solution that can perform the job. You must be aware when you think about needs assessment where your developers come from. Do they know the problems in your environment? How much of information do you need to tell them about your environment? Workflow analysis. Does the system change your workflow analysis or more importantly why does it change your workflow analysis? If it changes it to improve it then that's good. But if it changes it because it's just built that way that should not be accepted. That system will fail. It's also important to realize the difference between the actual versus the perceived benefit of the electronic medical record or in fact any medical information system. The actual benefit is at the moment what benefit will I get. Many designers, many people that want to sell you information systems will only speak about the perceived benefit. So in the future what would you have? In the future you could create a system that could automatically diagnose the disease. In the future you could create a system that will tell you how long your patient has to live. But that does not mean that it's benefit right now. I'm not saying don't think about the future. But I'm saying when you're assessing the benefit of a system think very carefully about what the actual benefit is compared to what the perceived benefit is. Do not collect data that is not beneficial for you and ensure that whatever data you collect can be analyzed and reported directly to you. The design. Ensure that you are fully involved in every step of the design. Remember that you have to tell the developer what you want and also keep in mind that the developer may not necessarily understand what you are trying to say. So you should insist that the developer uses the spiral development model compared to the waterfall development model. In the waterfall development model you give all your requirements to the developer. The developer creates the system, he comes back and he implements it. This usually takes a long time before he implements the system and what happens if there was miscommunication and he developed the wrong system or system cannot be used. All that time is wasted. Whereas with the spiral development model you can actually counteract this communication problem. You tell him a small bit, you give him a small bit of what you want. He then goes and develops that, he tests it and he brings and he shows it to you and then you see it. You see if this is actually what you want. If not, you can design again and you only lose a small amount of time. If it's the correct thing, you tell him again what you'd like to add to it, how you'd like to improve it and he builds on this. Of course he must take into the environment in which he is developing the system. The system must be flexible. The system should be built in such a way that a high end user, a super user should be able to change the system according to the needs of the environment. He should not be dependent on a developer or a computer scientist to actually come and change the system for him. In order to develop a system like this, you need to make use of what is called the generic data model. Testing must not be done in a lab. You must have a trial run of the system in the actual environment that it is going to be run in with full participation of all the developers and stakeholders. Also try to get independent evaluators and the reason for this is actually to prevent the MyBaby syndrome. Once developers develop a system, they actually feel that their system is perfect. There's nothing wrong with it. There's something wrong with the users and they will not evaluate it unbiasedly. So it's important to actually try and get independent evaluators. The system functionality. All systems are not as useful as people actually think they are and that's why systems fail so many times. You have to ensure that there is full comprehensiveness of information. You have to make sure that the system captures and stores all of the information that you require. There's no point taking the time after capturing information if this information is not what you need. If this information is not what is going to actually be used. Degree of structure of the data. And this deals with the retrieval and the analysis of the data. What degree of structure of data is being used? Are you scanning documents and storing it or are you actually typing out documents and storing it? The higher the degree, the more efficient or the higher the degree, the more value you will get out of the electronic medical record. Access. Can you have multiple read privileges? Does the system allow many people to actually read the data at the same time without giving them the right to actually change the data? Backups. How are the backups done? How often are they done? And this of course will depend on the environment that you actually are in. Where is the backup stored? All backups need to be stored in a external location, in a location that is away from where the original data is stored. What happens if the system fails? Is there a second system that comes into play that has minimalistic functionality? Or is there a paper-based approach where you record everything in paper and then once the system comes back, you enter them into the system? What is the ease of use of the system? How efficient is the system? How robust is the system if an error is made as the system just crashed? Importantly, does the system add benefit to the clinical environment? There's no point having a system that does not add benefit to your environment. Security. How secure is the system? Does it ensure confidentiality? Does it ensure integrity of the data? So whatever data you've seen is actually the data that was recorded and hasn't been changed in any way. Is the data private? System selection. This is also a very important aspect when it comes to developing, choosing an electronic medical record. Do you choose an open-source system or do you choose a commercial system? In developing countries, because of the lack of funding, people usually go for an open-source system because they feel that it's free. For open-source systems, yes, the code may be free, but the implementation is not free. You still have to pay someone to implement the system, to buy the technology, to lay down the infrastructure for the technology, etc. etc. etc. The actual cost of the system is still quite high. There are also other important things that you have to remember when it comes to open-source systems. Things like, is there support? There are many open-source software have been developed by students at the university. Once the project is over, once the cost is over, there is no support for these systems. You have to ensure that the electronic medical record that you are using has support. Security is a big issue with open-source systems because of the nature in which open-source systems are built. Different people all come together and add different pieces of code to make the software. It is so simple for some to just come and create a back door in the software. You have to be extra careful when it comes to security if you are using open-source software. What about testing of open-source software? Testing of open-source software becomes difficult because it requires a very complex platform to actually test these type of solutions. Of course they are open-source software that are built in such a way that they overcome these disadvantages. You should also think very carefully or read very carefully the small print when it comes to these systems. Many commercial systems that are trying to make a profit of you have small print that is just ridiculous. One example of what some commercial software might do is they might charge you very little for the software but they charge you for each data entry in your database. If you have a thousand patients you are going to end up with 10, 20, 30 thousand data entries in a short period of time in a matter of weeks. You must be aware of this small print because if you accept a system like that you will end up paying a lot more money than you actually should. So be aware of the small print implementation. You must have a phased rollout. You cannot roll out the entire system in the first go. Again this also speaks to the spiral development model. The rollout must be such that small parts are introduced into the environment. And this in fact is also advantageous when it comes to change management. Because initially you slowly start making people aware of the need of the system, of the benefit of the system and eventually they take to the system more easily. Slowly training them, taking them step by step they don't feel intimidated. And training, training is absolutely vital when it comes to implementation of electronic medical records and do not feel that training only deals with the training for the use of electronic medical records. You will find that there is an entire other dimension to training. Majority of people are actually computer illiterate in developing countries. They may be nurses, I even know of some doctors that are in fact computer illiterate. So training, aspect of training is training people on how to actually use the computer. How do you put it on? How do you send emails? How do you troubleshoot problems? It's only after this then you can actually consider training on the actual electronic medical record system. Support, you must provide support. Support should ideally be local. So that if you cannot get to the bottom of the problem by telephone or video conference you can actually drive down there and help. Finding champions. I can't stress to you enough how important this is. When you want to ensure a successful implementation of your system you must have champions. You must have a person in the hospital that or clinic that is actually on your side that is excited about this technology that will speak to people about this technology that will encourage them that will show them that it will work. It is absolutely vital. Creating super users is also a very important part of ensuring the long term success of your information system of your electronic medical records. Because the ideal situation will be super users managing the system. Super users trying to change things in the system. Rather than spending a lot of money on getting developers to come back and change things. And again the generic database model actually facilitates this. It helps with creating super users that can in fact change the system to facilitate whatever the new environment is. You must celebrate success. You must show people when things work. You must reward them when things work. You must learn from your mistakes and have an adequate budget. Always ask questions. Just because it is written in literature does not mean that the person implementing the system is not taking it the wrong way is not showing it to you in the wrong way. For instance studies have shown that holding and caressing animals can dramatically speed a person's recovery. That's what the teacher says. But does that mean if you give an old lady a snake to caress it will improve her recovery. So never take things for face value. Always ask questions. So what are the important questions to actually ask? The first question, the most important question is is there a need for the system? Systems should be developed where there are needs and not developed because it is cool technology. Not developed because someone got a grant to develop it. It should be developed because there is a clinical need at that point in time. Do all the components function correctly? Is it reliable? Is the system accurate? Is it fast? Is it well built? So does the system use a modular design, a design where you can actually add different components to what you want rather than having one huge system that is complex to actually use? Are people actually likely to use it? You must understand which parts cause what effect. How is it maintained? Who is going to maintain it? What is the cost of maintaining it? What is the long term sustainability of actually having the system? How can it be improved? Always think about how to improve these systems. Very importantly, is the interface intuitive and easy to use? Is the interface in line with the cultural environment in which you are in? In fact, I heard of an information system. Yes, it wasn't a medical information system. Nevertheless, it was an information system that actually failed in a country because the wrong colors were used in the interface. Those colors were seen as being negative and sort of full of bad luck in this environment. And people didn't want to use it because of those colors. So it's important to actually understand your cultural environment to actually build an intuitive interface. Does it communicate effectively with the other hospitals and components? And this is important, integration. Integration is absolutely vital if you really want continuity of care for patients. If you really want to improve healthcare. It is vital for different components to actually communicate with each other. Especially if you have the long term plan of a national electronic medical record. How does this system communicate with the other systems that are in place? How does this system communicate with the district health information system? What standards does it use? Does it use HL7? Is it robust? If a mistake is made, does the system just crash? If a mistake is made, how can you recover from it? Is the system robust? Thank you very much for your time. I hope you enjoyed this lecture. It basically was about trying to make you understand some of the questions that you should ask yourself when implementing an electronic medical record. Thank you very much.