Head of the Clinical Unit in the Department of Surgery at Worcester Hospital, Dr Riaan Duvenage, talks about how his custom eHealth solution has turned the hospital into a centre of excellence and the tangible benefits it has had for patients, staff and management.

We’ve been following your story at EHN for a couple of years now, but let’s start at the beginning. As a trained surgeon, what sparked your interest in eHealth?

 When I started at Worcester Hospital 15 years ago, I was the only full time surgeon. And when the Department initiated the community outreach and support programme I wasn’t able to take part because it didn’t make sense for the only surgeon to leave the hospital to visit outlying hospitals. This dilemma got me thinking about how we could establish virtual outreach support to make specialist expertise available to everybody simultaneously, 24/7. The obvious answer to that was a web-based system and as I learned later on, an interactive web-based system worked even better.

In 2006 I became interested in web development and developed the first version of my electronic clinical and administration system for the Surgery Department. Initially I thought of it as a small project for my Department, but when other clinicians saw the impact, they became interested in it too. I started developing it further and now pretty much the whole hospital functions on it to some extent. There’s a generic component to the system for the whole hospital, which includes the on call lists, a phone app for emergency theatre bookings, a TB alert tool and an adverse drug reaction report tools to report these to the Medicines Control Council, to name a few. There are HR tools, including online leave applications.  Then there are several specialty specific tools such as admission notes, operation reports, endoscopy and echocardiography requesting and reporting systems.  All of these tools capture data for audit and research, it generates printed clinical notes and documentation and many of them display on live dashboards.

I’ve since had enquiries and developed an interface similar to ours for Mitchells Plain Hospital’s Surgery Department, who will probably soon begin to use it. Kimberly Hospital, Port Shepstone and Tygerberg Hospital also expressed an interest.

When we first spoke to you in July 2014 you were running the eHealth system alone. Who manages and maintains it now?

I still do it myself but I am now keen to get role players from the IT industry on board, to ensure sustainability of the project. The maintenance required on this system is very light – the system is PHP-based; it’s a MySQL Linux server and I use a lot of code generators for development. What really keeps me busy is trying to develop new features for the system, and increasingly to ensure that it remains mobile friendly.

I’ve discovered that what makes it a good system is the fact that I work on it on a daily basis, and when I develop something new I can test it and fix any bugs quickly. My Department tests and works with the system all the time too, and they tell me immediately and directly when certain things take too long or don’t work or if tasks are duplicated. I can then respond with changes quickly and once everyone’s happy we then roll it out formally. On average, all this happens within a week. What we have is a great, working example of: designing systems in collaboration with clinicians, designing them to enhance existing workflow and to be inclusive in the process and responsive to the needs of the people delivering healthcare.

 How has management at Worcester Hospital responded to the system?

My hospital’s management and local IT Department fully supports me and we are keen to get my system officially recognised. During management meetings the heads of units are required to report on numerous clinical and corporate governance parameters, as well as clinical service parameters. Lately our presentations contain lots of data from my system from which all of us can show important QA data such as the exact length of stay, adverse events, demographics data and lots of other things. A recent addition is live dashboards that provide real-time data. The hospital’s CEO often uses that information when presenting to top management and to inform decision making.

Can you share with us how the clinical data has been used to plan services or procures?

Yes, over time the system has generated enough data that enabled us to assess and adopt our theatre services to improve theatre efficiency. A good example: My Department’s operation data demonstrated a progressive decline in elective surgical procedures during the second half of last year, due to an increase in emergency cases and an apparent shortage of beds. Further analysis of the problem, using our data, pointed to ineffective theatre utilisation rather than an actual shortage of beds. We recognised the need to implement a dedicated 24-hour emergency theatre, something we did not have up to then.

So we managed to get an emergency theatre implemented along with a web-based electronic waiting list for patients awaiting emergency surgery. The electronic emergency theatre list is simply an interactive web-based implementation of the provincial emergency theatre triage policy: the system automatically prioritises patients according to clinical urgency, ensuring fair and appropriate use of a scarce resource. It ensures that the patients who need surgery more urgently are operated before less urgent cases. It allows surgeons to book an emergency case from their cell phones and it also provides essential anaesthesia related information so that in most instances, phone calls to the operating room can be avoided. Through this system emergency theatre usage data is also captured and thus quality data about the efficiency of our emergency theatre is also collected. Better theatre utilisation eventually increased our elective procedures back to the numbers what it was before the increase in emergency cases. An example of how quality data enabled us to do more with the same resources.

Another example is how our data showed that only half of the patients we operate are actually booked on lists in advance. The other 50% present with emergencies of varying degrees, or are urgent and unscheduled cases, so we need to have quite a bit of redundancy or surge capacity in our theatres to accommodate those patients. At first glance it may appear as if the Surgery Department does not utilise our theatre time optimally, if one only looks at the operation bookings for the next two weeks. Our data, however, demonstrates that we need that redundancy in order to manage the urgent cases, typically cancer surgery, that we know will present over the next two weeks, within a reasonable time. The alternative is unacceptably long waiting times for urgent cases such as cancer procedures.

Another example is how our data demonstrates the ratio of length of stay versus unplanned readmissions. It’s a powerful indicator of the quality of your service; you can have a very long length of stay and no readmissions, or a very short length of stay and a lot of readmissions. You have to get the balance right. The data generated by our web system tells us that an average length of stay shorter than four days means that unplanned readmissions will go up significantly over the next month. That data put me in a position to report that we were running in top gear as far as bed management is concerned, and if we needed to accommodate any more patients we will in all likelihood need more beds.

And from a user point of view, can free text also be entered into the system?

A lot of careful thought went into the system’s design. Right at the beginning I discovered that it was important to try and limit free text as much as possible and rather use dropdown menus where appropriate, because the quality of user input varies: some people type in capital letters and make spelling mistakes, and users even switch between Afrikaans and English. All that makes it extremely difficult to capture quality and usable data. But of course there are instances where you have to use free text, and that’s where my clinical background is advantageous because I know how a clinician’s thought process works.  One has to strike a balance between obtaining compliance with minimum data sets, yet at the same time providing the clinician with free text space to write in their own words. I think we got it just right.

Data validation of the user’s input is an extremely powerful tool: it can enforce compliance with provincial policies and protocols, and it can also be employed to provide clinical guidance to staff. Our burns assessment tool is a good example of this. That’s the whole idea behind virtual outreach and support.

Another advantage of being a clinician involved with web development is that I’m obviously familiar with clinical workflow. I know when it is practical for a clinician to pull off his or her gloves and use the computer, or when a tablet or cell phone will be more appropriate. Also when it is not the time to use technology at all. That is one of the ways to get clinician buy in to use a system. The programming languages and platform I use is actually not all that important, it’s the workflow and principles that are important.

From an outsider’s perspective, I think there’s also a lot of interest around how the system has maintained autonomy within a public health setting. Where do you see your system fitting in with provincial or even national systems?

My system is not intended to compete with existing platforms such as Clinicom or SINJANI, or as a replacement for any system that the government already has in place; it’s a custom-built web-based clinical tool that is primarily intended to generate quality clinical documentation – all of which can be printed for the hospital folder – and to provide clinical guidance, and which has since been found to useful by other departments. It has the added advantage of quality data capture and therefore has the real potential to enhance the efficacy of systems like Clinicom or SINJANI, by acting as a feeder system for these systems.  Of course, once we reach the paperless stage, the clinical information is all in the cloud and accessible so printing is an intermediate stage.

While we have the benefits of agility and customisation because it’s an in-house solution, we are also addressing the need for quality data head on.

I’ve designed the system so that we can improve the accuracy of our data and actually use it for better service delivery. Outside of clinical data, we capture data for auditing purposes, research, management, etc. All the data entry is carried out by doctors as part of our normal workflow, so it’s of a far better quality than when clerks are doing it. You need some clinical insight to do proper ICD-10 coding. Our system ensures that operative procedures are automatically ICD-9-CM encoded – just that functionality alone reduces the administrative burden on clinicians enormously by preventing duplication of administrative tasks.

Integrating into a regional system is something we will most likely need to look at in the future as our system will without a doubt enhance the efficacy of software systems used by the Department of Health (DoH). I believe that it is of the utmost importance that as a provincial DoH, we should first agree about what we want to measure: that will dictate the reporting norms and standards such as minimum data sets for each specialty and service. Of course, these are things that evolve over time as the healthcare environment changes, so the information technology platform used should be able to rapidly accommodate this evolution. The platform used should not dictate the norms and standards of data, and should not limit the natural evolution of these. The advantage of our system is that even though its tailor made for our hospital, the underlying principles can be exported to other institutions and other IT platforms. It works very well because I can, often within hours, respond to a problem with a workable solution that in most cases avoids duplication of work and often has built in additional advantages beyond the primary purpose of the tool. For example, I later added parameters of the SSI bundle of Best Care Always to our operation reports, to easily monitor compliance with the provincial SSI policy.

Can you give us another example?

Recently, some physicians wanted to capture data of patients with known or suspected TB and have this reported to someone at the regional office whose job it is to go out and follow up with these patients and see if they have been to the clinic or are getting their medicine. In such an instance a paper-based system simply won’t work so I developed a web tool which also functions as an app on your phone. Doctors would scan in the QR code at the patient’s bedside to open up an interface on their phone. They would then take a picture of the folder with the patient name and address which is then attached to an email and automatically sent to the appropriate person. Alternatively, the same tool can be used from a tablet or desktop: once again an example of appreciating the clinical workflow to ensure compliance.  The tool should be available where and when the clinician needs it, either at the bedside or in the office or clinic. The additional advantage is that unlike a paper-based system, the data can easily be analysed in real-time and trends can be spotted as they develop.

How long did it take you to develop that?

That tool took me about two hours as it was based on existing tools that I developed before. I created the reporting tool the same evening after the problem was mentioned to me and sent out a couple of test entries. Within two days we started using it. That’s what I mean by effective responsiveness. I’m always keen to solve new challenges and to figure out how to make things work. It costs me sleep sometimes, but once I get started on a project I won’t rest until it’s complete.

For more information contact news@eHealthNews.co.za, like us on Facebook or tweet us @eHealthNewsZA.