Go Paperless! Bridging the Gap Between Audiology and Electronic Medical Records

Learning Outcomes

After this course learners will be able to:

• Define the difference between EMR and EHR.
• Compare the current process for handling audiology patient data vs. new electronic method described.
• Discuss 3 ways electronic integration can enhance your practice.
• List other Software Integration Group (SIG) services that are available.

Introduction

To begin this course, let's review the current landscape of EMR. Knowing the basics will give you insight as to what is available in audiology today and how we can address and handle the different situations we come across. Many of you may have heard of Electronic Health Records (EHR); then there is the Electronic Medical Records (EMR) and Office Management Solutions (OMS). The industry in Electronic Medical Records started the trend several years ago to change the term to Electronic Health Records. This did not seem to stick very well because if you have ever tried to type "EHR," it always self corrects to "HER." In most correspondence, we usually refer to EMR.

Categories of EMR

EMR is broken up into four categories or types. See Figure 1.

Type 1. Type 1 is usually seen in large hospitals (e.g., EPIC, Cerner) and they are generally very customizable. For each application, they are customizable to the point where the product itself is even renamed. Compared to the other clinics within a hospital, they usually have a much smoother integration to EMR. With all of the different hardware which is taken into consideration, audiology has been generally the last to integrate with the EMR because of that fact. When you look at the primary use in type one, it is the sharing the records across a large group. When we refer to EMR, HL7 is the programming language that is common amongst all EMR solutions, and it allows you to become compatible.

Type 2. Is similar to Type 1. For example, it is similar to Epic, yet it is a shared resource. So instead of having that EMR solution deployed within your facility, it is somewhere in a cloud, and multiple customers would be using it. It is much harder to implement or integrate with this type of EMR solution. This is because it is a shared resource and to be able to determine which account is using it. Currently, our Otobase^® solution would require that EMR do more customization and not just use their standard package. One that comes to mind is Athena when you are trying to identify what EMR solution you are using today.

Type 3. Is more standardized. An example of this EMR type is AllMeds, which is very popular. If you see one version of AllMeds, they are pretty much all the same. The vast benefit there is once a connection has been established with a particular device, it can be reused multiple times. They tend to be much easier to upgrade since everything is standardized and more straightforward integration. These are primarily used by ENT and single clinics. Type 3 is HL7 as well. When a practice needs more functionality, Type 3 can be very beneficial compared to the other kinds of EMR.

Type 4. Lastly, Type 4 is more of an Office Management Solution (e.g., Sycle). It is an EMR itself, just self-contained and doesn't use HL7. Type 4 is suitable for scheduling, billing and performing different tasks that are usually deployed within an EMR. It is very specific and geared toward the audiology and dispensing market.

Those are the four kinds of categories.

The solutions with Otobase and some of the others that I'll discuss today don't integrate with the Office Management Solutions. This is primarily because most of them use the Noah engine, allowing it to be Noah compatible. Like in our instance with Otobase, it can also utilize the Noah engine, and you couldn't have two solutions, both using the Noah engine.

​

Figure 1. Different types of Electronic Medical Records (EMR).

Audiology & EMR Today

The goal with Otobase is we want to help automate as much of the processes as possible. Automation can help eliminate the errors and removes the need for paper in the record keeping. We also want to keep in mind HIPAA compliance and all of those types of scenarios.

Figure 2 shows an example of where you have a standalone Non-PC based piece of equipment (e.g., audiometer, tympanometer). In most cases, you would have your EMR solution, and then you manually have to enter the data into those. They are entirely separate. Everything that you then enter into the EMR would be manual so you are typing the report in there and you are reentering any audio information. In some cases, you may be writing down the audiogram on paper and then getting those into the Electronic Medical Records, in more of a scanning fashion. We see that quite a bit.

Figure 2. Example of standalone Non-PC based equipment.

The next set up that we see in Figure 3 is where there's the EMR that is then communicating orders and records to a computer that may be in your booth or next to your workstation, but you don't have a direct connection. In many cases, you may or may not be using Noah. If you are using a PC based product, you may print to paper and then go through the scanning process and again, manually attaching the records. Which again can create error where if you have, multiple "John Smith's" of different ages, in this scenario some institutions have departments that that is all they do is attach those records, into the EMR. Others, the audiologist is doing that themselves. The thing we've noticed when EMR was integrated back in the day was the implementation of EMR added quite a bit of time to how long you had to spend with a patient. That was another motivating factor, when we were looking at designing Otobase, is how do we recapture that time, so you don't lose time having to comply with this EMR solution? 

Figure 3. Example of EMR without direct connection. 

A better solution printing and scanning, if you are not prepared to transition to an automated solution would be instead of printing the paper itself, you would create a PDF from your report. Figure 4 shows this set up. Almost every computer can have a print driver, or a PDF print driver installed. When you go to select a print, instead of printing the paper, you would then print to a PDF which then saves quite a few steps. Now all you have to do is attach that PDF to the encounter and save a few steps. When it comes to beginning the process of automating into EMR, there are a few options out there. You would take each piece of equipment, and most of the manufacturers will provide the source code needed so that they could output that data, directly to the EMR (i.e., Allscripts, AllMeds). I know they have some direct connections with some GSI products and that is a good solution. The downfall to that is of course when you change products; then you have to have a new connector written. If there are software updates or a firmware update for that product, you might need to then change that connection. You can imagine when you scale that, it could get quite expensive. The other one there is AudBase. They were one of the first to come to market with more of an automated solution that could also give access to analytics. One limitation they have to date would be that they focus primarily on audio and tympanometry of a few manufacturers. The one thing with Otobase that we wanted to avoid was creating multiple processes. If you are going to get connected, automatically to EMR, you want everything connected.

Figure 4. Example of EMR where a PDF is created and attached.

In this situation, you would follow this automation plan with audiogram and tympanogram but being that it is not Noah compatible, you still have, you to do manual processes. After you complete the audiogram and it is time to move on to doing a hearing aid fitting, you would then have to follow separate processes. You would manually reenter the audiogram and proceed with fitting. It is important to note that when we come in to help, we evaluate and coordinate with audiology and IT. Because IT may put a requirement, that you cannot do certain processes and where you can do other processes.

Otobase

With the Otobase solution, we wanted to evaluate what was in the market today and how we could recapture some of that lost time when it comes to having to integrate with EMR. Most audiologists today utilize Noah. So what we chose to do was we wanted to take the power of Noah and integrate it into Otobase. Essentially in Otobase is "Noah EMR." It allows the EMR system to communicate directly with Otobase and then to anything that is Noah compatible. To expand that a little bit further, to eliminate the need to have manual processes, we wanted to find solutions to how could we get non-Noah devices (e.g., Evoked Potential, VNG) to become integrated. We have found solutions that allow us to integrate non-Noah devices as well.

SQL Database

With Otobase we have a Structured Query Language (SQL) database, just like with Noah today. Thus, all of the raw data would stay within Otobase. You could look at any historical records could retrieve and view historical audiograms. When you hook up hearing aids, you could pull in the old programs and then could communicate across your network and not have to manually enter any data. The goal here would be when you have an audiogram and walk over to your fitting solution, that data would reside there, and you could just continue with testing. Then when you sign off, all of that information can be reported back into the EMR.

Like I had mentioned earlier, Otobase was designed to look and feel just like Noah. When we come in, we extract your Noah database, uninstall Noah, we convert your Noah system license into a Noah engine license, install Otobase and then reimport all of your databases. 

You would have all of your modules at the top. You would have your existing Noah database with all of the sessions that you have captured. There's a little orange button, when an order or a message comes in from the EMR that would light up and it would indicate that you have, a task to do, you would select it, it would import that patient information and it would match it to your existing database and create a permanent link between that data and the EMR. 

A practical benefit of this feature is: If there were a name change and address change, the EMR is always the master, and it would then update, the database within Otobase as well.

Report Manager

The other unique thing to Otobase is you have the report manager. That would be a direct link to where you could see what report and data were sent to the EMR. You don't necessarily have to open up your EMR, but it would allow you to then review that as well. When you are done doing all of the different types of tests that you need to do, you would then sign off.

Customized Reporting

When we were developing the Otobase solution, we wanted the ability to have some flexibility in the types of data that you wanted to report. I mentioned earlier the direct connection to where you had each device connected to your EMR and you are transmitting the data that way. With this, you can customize it. 

One example would be if you had one doctor that liked viewing audiograms separated left and right ears and you had another one that wanted them combined; this would allow you to have templates explicitly designed to your preference. You could have the data that was more focused toward pediatric testing where the adults would have templates that were designed more for their use. You also can have templates that wouldn't be focused on EMR but could be customer facing. This may not be one that you'd never send into the EMR, but within Otobase, you would be able to manually print out a report that could be a take home for the patient. All of that can be customized into the template and are relatively flexible. 

There are a few limitations, but for the most part, we've been able to accomplish, almost anything you could imagine. 

Noah and the Oto World

Noah is kind of a launch pad for audiology. Noah can usually hold between, 30,000 to 40,000 clients. It depends on how long you keep that history and if you manage an archive data. With Otobase you have quite a bit more storage, but utilizing Microsoft SQL, it can go up. Without Otobase you have again the Noah engine. It is compatible with everything. OTOsuite would just be a module within Otobase or Noah. 

I know that Otobase and Otosuite^® get confused quite a bit. Otobase is our EMR solution, and OTOsuite is the user interface for all of the different pieces of equipment. Depending on what equipment you have—you may have another suite. For GSI equipment, I know they have GSI Suite, and it could reside within Noah and Otobase as well. 

Then finally there are Otosuite Reports which is the designer that allows us to customize templates and it can be utilized with both OTOsuite and Otobase.

Figure 5. Comparisons of NOAH and Oto products.

Another trend that we see is where a clinic is moving toward the EMR integration, but they are not yet ready to make the tie in. They would like some of the benefits of Otobase, and one of the significant benefits we have with Otobase is, you do have a mix of products. With Otobase, you could have all of those different pieces of equipment come back to Otobase and then print one report and have that get attached manually before you tie in the EMR part of the Otobase into your Electronic Medical Records. This gives you a landscape of what I call the Otoworld.

Reporting Methods

The next thing to consider with Otobase is how you want to integrate? These are all things that we would go over in our evaluation meetings with audiology. With my division, we typically go in and discuss with the audiology department first to get an idea of how they work today and how they want to work? We look at their workflow and then what data needs to reside within the EMR. With Otobase, we have three options:

Customized Base 64 PDF. Most of us have seen a PDF. In your clinic, if there is a concern about how much space is used in the EMR because they may charge for data storage. A Base 64 PDF is not a flat file; it is just a bunch of codes. Then within the EMR itself, it rebuilds it into a PDF where you can then see it. As far as the user experience, you don't know what the difference is. As far as the IT discussion, it is huge because it doesn't take up much space. This would be where Otobase can send that code to the EMR, and it then resides within the encounter or the visit for that patient.

Linked PDF. There is another option we see a lot where they don't want to utilize any storage space within the EMR. That is where Otobase can link the PDF outside of the EMR itself. Thus, it would reside on a shared drive or somewhere separately.

Embedded Discrete Data. One of the new features unique to AudBase is sending discreet data. Embedding discrete data instead of sending a design report or a PDF would just send the raw data that would populate fields within the EMR. The positive to that is if you wanted to do any analytics within the EMR you could pull that analytic data. The downside is typically most software companies release several updates a year. If we add a new element that did not exist within the EMR, we would rewrite the connection to add those additional elements. The goal that I try to influence, when we look at the integration is automation. The removing of any manual task whatsoever so you don't have to manually enter data anywhere. Then also the maintenance.

One thing to note though, in most cases in audiology, you just need access to all of the historical data and that would always be available within Otobase itself. In many cases, what needs to be seen within the EMR is primarily focused on what the doctor wants to see. He doesn't necessarily need to see hearing aid information or look at historical data.

Software Integration Group

EMR integration. I have been doing this for almost 30 years now, and as we progressed in audiology into PC based products, I saw a growing need. As a representative out in the field, you would have access to the product and service individuals calibrated, fixed the products, but there was no one really that helped with the software side of it. We brought that to Otometrics and Natus to where we can help bridge the gap between the IT and audiology.

Backup solutions. I would travel around the country, and I'd look at these large Noah databases. When I'd ask if they back it up, it is very rare in an ENT or smaller clinics that they back up the data. You need to evaluate if something happened and you lost all of that historical data, would it be the end of the world? In most cases, it is simple and doesn't cost much to purchase an external hard drive. We tend to see Noah has its backup solution, but clinics are backing it up to the hard drive that it exists on, which of course if it fails, you lose that as well.

Networking. I often see two PC based audiometers sitting right next to each other, but they are not networked. Also, I often see the audiometer that was Noah compatible but not connected to Noah. Thus, the clinician would have to manually enter in the date to proceed to a hearing aid fitting. I've entered enough manual audiograms to know that it is not easy and I make mistakes. I'm sure you do it a lot more than I do but, having the data appear would be efficient.

Consulting. When we meet with a clinic for the first time, we want to understand what your goals and needs are. If you are in a hospital environment where it seems hard to communicate what your needs are, or IT tries to implement what they say their needs are, we can help bridge that gap. Often, IT is updating all of the different modules that occur, and we have solutions that can help automate that process. Instead of interrupting clinic during the day, they can automate the process of updating all those modules.

EMR readiness. When a clinic is ready to integrate with EMR, we want to find whatever the best solution may be. In many instances, we first evaluate if that clinic is ready to integrate with EMR. We have to look at your current network solution. If you are in a clinic where you have multiple offices, do you have access to data in the other offices? PC locations and I'll give an example of that, here in a little bit. What type of audiology equipment do you have? Workflow is one of the most common concerns that we can help with.

Preparation is the Key To Success

Database Location

If you have multiple clinics and each location their own Noah database, this would not be ideal. Step one would be centralizing all of those clients by combining all the different databases into one central server. This centralized or virtual server could even be a cloud solution. Audiology clinics and hospitals usually use virtualized servers which essentially is a cloud solution. It is located within the facility. Whatever the answer may be, you want to get all of that data centralized into one database. If you have patients transfer from one location or another, you would have access to all that historical information.

Current Equipment

The next step would be managing the expectation of what equipment the clinic currently has.  We evaluate what you have today and how we can integrate it. Most commonly, you have clinics that use a GSI 16 or GSI 61. Some of those are Noah compatible and have the port available. However, the clinic may not have the software that makes it compatible. 

The critical thing to look at is a lot of people don't integrate, their audiometers at that stage. Having the benefit of not needing to reenter that information when you go into the fitting stage is a huge time-saving benefit, and it is a much lower cost. 

With EMR, we want to avoid having two computers sitting on your desk. With Otobase we can eliminate all that down to one computer because now your EMR solution and your test equipment can all reside within one computer. 

Whatever your circumstances may be, we evaluate that when we walk in so, we can help offer some solutions that might help or improve the way that you do that today.

Evaluate Current Environment

Figure 6 shows an example that we see quite often—where you have a GSI audiometer that does have Noah compatibility. Additionally, a Verifit that also has Noah compatibility but so many times I see where they just don't connect them. 

When we are looking at setting up your clinic, we evaluate what is compatible and connected with your EMR with Otobase. We want to go in and fix all of these types of issues before we proceed. We then centralize your database. Now the data can flow between all of the equipment and when we activate EMR and Otobase, you are good to go.

One of the benefits that we have with our Aurical^® fitting solution is being able to separate the actual test box from the mic system itself. Thus, they could be in separate rooms. All of this could be then positioned more ideally so that you can progress and work with patients, easier and faster.

Latest Software. Prior to launching and getting ready to do an implementation of Otobase, we also want to ensure that you have the latest modules. We would want to get updates of all the different hearing modules that are available so that you have the latest and greatest when we go live.

Figure 6. Example of equipment that is NOAH compatible but connected to NOAH. 

Current Patient Flow

You may have an audiometer sitting outside the booth and then have another PC inside the booth that may handle tympanometry or OAE. In our discussions before going live with Otobase, we want to make sure you could have the most efficient workflow. For example, performing an audiogram outside the booth and then transitioning inside the booth to do a tympanogram. In Noah or Otobase, you couldn't have the same patient open in two locations. You would have to log out of the patient here, go into the booth, find the patient again, open them back up and it is just a lot of extra steps. We looked at the efficiency of adding a touch screen.

Current Noah Database

Finally, the last thing we evaluate is the Noah database itself. It is essential for us to go in and evaluate what you are entering in Noah because most of the times we see very little information. It may just have the first initial and last name and no date of birth. Whatever your circumstance may be, we can help evaluate that and create a solution for you.  

To get started with your transition to an EMR-ready clinic, complete a quick Assessment Survey and using entry code “EMR19-AOcourse”. This survey covers basic practice management and software applications questions to allow for consultation tailored to the unique needs of your clinic. To take the survey or for more information, please visit www.otometrics.us/otobase