Which country are you in? I'm a researcher, not a clinician, but I can tell you that many Electronic Health Record systems are designed to make administration and dealing with insurance companies easier - they're not designed to help give care. If I were in your position, I'd hold a meeting with a few other SLTs where you map out the documentation you need, what kind of data you need to access, etc., and then distil that into a requirements check list. Then ask vendors to show you in detail how the product will fulfil your requirements. Look at the number of steps this will take, and how intuitive the options are. Email me if you'd like more info.

We have been using electronic notes for almost two years within the Adult SLT Service in Sheffield. My personal views are as follows:

Positives: The software we use works well in general and is easy to navigate. As well as storing clinical notes, it helps us to organise our caseloads and waiting lists and provides an appointment management system. The software allows us to upload assessments and written samples as attachments. I am not aware it enables us to upload voice / speech samples. We have integrated an outcome measurement system within our database - this should make outcome reporting easier; however, so far we have had teething problems capturing both activity and outcome data and have needed a lot of support from our trust's IT dept..

Negatives: Many of us feel it takes us longer to document clinical activity, as we are still required to write in medical notes and then input SLT notes electronically. You need to consider adequate computer and software access within and outside the SLT dept. (if there is a lack of database access on hospital wards, staff may still need paper copies of notes to refer to once away from SLT dept.). Increased use of IT could cause adverse effects on health.

We use the electronic clinical documentation, however we do not have an especific software, we use the world and PDF in a file for each patient and in the case of the speach and language test where the used of paper is necessary. Once the test is completed we scan it. This way is so easy and usefull.

Alfredo... are your records housed offsite? If not, what is the plan if there was a fire in your facility that destroyed the computer that housed your electronic records?

Alfredo,

The SLP dept had a hand in creating the templates for the electronic documentation that was specific to our discipline which was great- I recommend you request to be an active player in creating those templates. I think it takes longer to document electronically but I come from the old school of triplicate forms and paper charting which I had down to a science. Be sure the text boxes are big enough to write a proper narrative. This is often in issue, we have a limited space to write our impressions which often is not enough in a complex case. I think smart phrases are ackward to use but others probably like them.

You have already received some very helpful comments. I think the sophistication of the technical personnel assisting with going to a paperless system will greatly affect the ease with which you make the transition. I have had experience in a Speech Pathology Department with a dedicated IT staff very familiar with the needs of speech-language pathologists and audiologists. Therefore, they were able to problem-solve and initiate processes and develop in-house digital forms that really eased the load. Contrast this to transitioning to paperless when IT is less familiar with your functions and you don't have dedicated and consistent support. I believe it is important to communicate well with IT and not shortchange the planning prior to implementation. Advantages: With a good record-keeping system, you will become more efficient and well-organized using a paper-less system.

Disadvantages: Transition from paper to paper-less can be daunting. There are also issues of confidentiality of files; what to do when there are power outages; keep a back-up minimal paper system in place and have "emergency practice" periodically--just like fire drills, so that things do not fall apart when and if you have a major power failure and/or problems with the servers. Yes, electronic files can be lost, damaged or hacked.

Thanks to you all for your very helpful replies. I am hopeful that we can design a system that allows us to reap the benefits of an electronic sytem without falling into too many pitfalls! Of note we have onsite IT backup and they would have good insight into our clinical pathways. We will be working closely with them in designing the system and they will be available for ongoing support.. We have also highlighted the importance of ease of access to handheld devices/computers to allow timely input of data. Which perhaps leads me to another related question: has anyone had experience using portable devices (tablets/netbooks) for recording clinical documentation?

Hi, Dierdre, saw your latest post about experience with portable devices: tablets/netbooks. I have limited experience recently and in the past used only desktop computers that were stationary for input. I will follow this post to determine what others suggest.

Thanks Nola,

To date we have only used PCs (for recording receipt of referrals and activity statistics), but would like to start using portable devices in certain situations e.g. for informal language assessments, therapists can record directly into electronic patient record, rather than on paper and then scanning to patient record. The handheld devices give rise to concerns about wifi onsite/care of devices etc, so others real life experiences with such a system would provide useful extra information.

Hi, Deirdre,

In terms of Wi-Fi, I imagine you will have to use a password protected system, so that only key personnel can log into the site--just as you would with a standard file drawer; only certain individuals may log in. With the new options for tracking devices and wiping them remotely if stolen or lost--it takes security to a new level.

I imagine you are looking into some type of secure server, with peripheral devices used to access the data on the server, rather than storing info on individual devices. It reduces the individual risk if individually issued devices are only used for access and uploading without storing info on the peripheral device. I might be speaking at too elementary a level. Forgive me if that is so. I look forward to following other responses!

Sincerely,

Not too elementary at all Nola! As a clinician this is not my area of expertise. I will pass on your comments to our IT dept as we address this part of the project. Thanks for your ongoing helpful input.

Hi Deirdre,

We could chose to cook pizza in our own kitchen or purchase one from the pizza restaurant. The former gives satisfaction and freedom to follow our whims. I suppose in a way, IT is somewhat like pizzas.

I wrote and set up an information system that we have used for the past 6 years. I did not build for SLT but for haemato-oncology but the concept is the same. Perhaps the difference is, SLT will have sound data included.

It is still in use. Built it from scratch using client/server model using delphi and mysql (for the database) in 2006. Did it DIY style (without formal IT training) and took me about a year of sore butt to get it going. There are a lot of helpful individuals in various forums which are more than willing to help. That was before the era of researchgate. Now it is even better.

Our 800 bedded hospital did not have electronic patients record then and still hasn't. But we have intranet workstations that linked the entire establishment.

What was my need?

I wasn't interested to go paperless. As a clinician, I need fast information retrieval and updates. There are many personals involved; doctors, nurses, staff working in shifts and no one can remember every patients. Patient or relatives may call or walked in to state a new problem or progress and we need to get assess to the patients profile quickly and also to update. This may facilitate the next person whoever he is to follow the patients development. The consultant may not be directly involve but he too could get access to these informations as well. He may not agree to the plan and adjustment could be made. The hospital I worked in had a good centralized patient case records. Nevertheless it takes a couple of hours for the case records to come to the wards. Worse if the patient was just discharged or just went to the clinic whereby his or her records is still in the holding bay. It is also a problem in weekends or long public holidays, as they started enquiring why we are making the folder request when the patient is not admitted.

So I need a system that could provide information quickly to anywhere in the hospital and could be updated in real time.

What did I focused on?

Unlike the full fledged IT system, which put a lot of emphasise to biodata, admission,discharge and administrative procedures, I kept just minimal biodata enough for communication. Make sure there is room to keep as many phone numbers as possible. Mobile numbers keep changing.

I mainly focused on clinical data ie patients progress notes. I wasn't obsessed with statistics so most of my data entries were open. If you are keen with statistics then you may want to standardized your data entry with more close options.

What did I need?

Initially I shared folders across network. It contained files of patient profile written in words. I later went into microsoft access. The IT department got upset when they got to know. File transfer like this uses heavy bandwidth. Our intranet runs on old copper cables and frequently breakdown. If you are assessing your files located on a computer in one end of the hospital from another end (clinic) it causes heavy network traffic and congestion. They would only tolerate data packets not entire file. Someone I know at that time was using delphi (pascal) with mysql. Mysql is free for non-commercial works and still is. I purchased delphi developer under academic licence (around USD500). There are languages you could use now which comes free, such as java, Q language etc. It so happened I chose delphi. I bought one desktop (bare) to be the server and installed EasyPhP (free). It has mysql incorporated within. I wrote two applications. One is the server application and another is the client application. The server application sits in the server where it communicates with the mysql database. This was the hard part but perserverence is the key. The client application is installed in whichever workstation in the hospital which you want to work in. It will communicate with the server application to fullfil its task. By the way the academic licence did not allow networking. In 2010, as the project was running into its 5th year, I purchased the full licence to make it legal!

One thing I did was I kept the server in my daycare. Reason. In case of power failures especially during period of thunderstorms, the server desktop which is connected to a backup generator line, will still run. I eventually also included an APS which is essential to prevent data table from getting corrupted due to abrupt power disconnection. Happened several times. I had a version of client application kept in the server desktop that could read the datafile. So in such an event when the intranet is down, patients data is still accessible, but on a single computer. Better than total darkness. I understand that some of us will voice their concern of loose patients data security. The server should have been located in a secure place. There are pro and cons.

We have manually backed up the data on thumbdrives. I did not go into RAID. It cost money.

We installed Wifi and was working with notebooks running on windows. We were able to access data at bedside. Anything that could be assess via cables could also be assessed via Wifi. We were able to show our patients, their result trends while they lay in their beds. I believe (we were yet to try) it should not be a problem with window based netbook. Ipad or other google device will be totally a different story. The client application has to be rewritten for none window system. Not for delphi I am afraid.

I thought it will be nice if we could view the data from home when our junior officer is discussing a case over the phone. I had to draw the line. The data should be encrypted if it was to leave the hospital intranet but I was not prepared to go onto another learning curve. So it was confined only within the hospitals intranet.

It has since gone through 9 revision/upgrades. We eventually added a discharge/clinical summary to be given to patients. To overcome double work, we printed the clinical summary and pasted in onto the patients case sheet. The whole system was created based on what and how we were working. We did not have to adapt our work to a commercial system costing millions. A couple of thousands just to make slight changes.

For the last 10 years, there has been an ongoing exercise between the IT and various department. For now, the exercise has been focused on laboratory results. It has been slow. The trouble I sense was, that the IT personal took a while before he could understand his clients need, and the fussy client sought for perfection and keep making adjustment to the product. This delayed system implementation. In my case, I fully understand of my own limitation as a rookie programmer and was just SO HAPPY to see it launched. I eventually made the improvement during revision.

So we had a homemade pizza on a shoe string budget. You could have your pizza too. :)

Hi, Abu,

Your example of pizza made at home vs. pizza purchased at a shop was a great example to clarify the relationship of IT to the function of a healthcare facility. With your technical background and 6 years of experience, you provide some excellent examples. In addition, you add several significant points, including the importance of speedy and easy retrieval of client information. Given the challenges to budgets in many facilities, your final point of "homemade pizza on a shoe string budget" (a clinical data storage/retrieval system specific to your setting) is most desirable.

Thanks Nola for the kind words,

I went through my entry and I realised I forgot to mention a couple of things.

Firstly I had to have a good relationship with the IT department. I needed them to provide me with a fix IP address for the server. Without that the system could not traverse the entire establishment.

Secondly, unlike a service clinician who is onsite at most time, an academic clinician might be located outside his or her facility more than half the time. We still need to get assess to the system. What I did was, install the same client application I had on the server on my laptop and intermittently feed the database on my laptop with the backed up data. So I may not be real time (maybe a week behind depending how busy or lazy I am at updating the data), but there are enough information to help me profile the patient when my junior officer called. They could fill me in the latest if needed. So wherever I am, if my laptop is with me, I could still provide a sensible response to a query.

One thing I have learned over the years, we somehow get over possessive with data. Unless the data is stored in your own backyard, you have very little say. I could do the above because the data was stored with us. If it is with the IT department, I am sure they won't allow it. A lot of data security issue is going to raised. Hands down, I will surely lose the debate. Nevertheless. the primary objective of the whole exercise is for the end user to have information in the finger tips, for decision making.

So, I feel if Deirdre wanted to discuss with the IT department, this issue should be touched on. I suppose, some work around can be arranged. There is little point if you have a good database, but inaccessible to you more than half the time, because you are outside on field work or visits.

Abu, thanks for your follow-up; there are advantages and disadvantages to localized control--just as you point out.