Archive for Blogs

Making eClinicalWorks Third-Party Data Transfer Possible

You have data in eClinicalWorks. You may be using a third-party service supporting your practice, or there is a third-party software or service with which you would like to work.  These third-party services and systems could do a much more efficient job for you if they could communicate with your system and exchange data. If only there was a way to make that happen …. Oh, wait! There is!

At Mi7, we believe that your eClinicalWorks data is there to work for you, helping you enhance patient care and build efficiencies into your practice. While eClinicalWorks provides a multitude of functionality, there may be other options for providing a specific function or service better outside of eCW.  We’ve done scores of projects over the years to accomplish this. A recent example illustrates what’s possible with data transfer and integration.

Leveraging Third-Party Data Transfer to Facilitate the Collections Process

Many practices contract with collection agencies to help with their balance aging, outstanding receivables and collecting payments. In these scenarios, patient billing and payment histories must be shared with a third party. In turn, the results of the collection efforts and payments made,  are shared back to the practice for recording into the patient record in eClinicalWorks. It is potentially a manual and tedious process, full of opportunities for human error.

The good news is, that this process can be automated and Mi7 can make it happen. We recently developed the following solution for a client to automate the transfer of data between eClinicalWorks and their collections agency:

  • Patient financial data is extracted from eClinicalWorks for those patients who have outstanding balances with the practice.
  • Data is uploaded to the third-party collection agency, mapped to the appropriate fields in their system.
  • Patient financial information and payment information are then transferred back to the practice, with payments posted within eClinicalWorks.
  • A secure environment is used for the transfer, helping to ensure the security of the data moving back and forth between systems.

In this particular case, Mi7 created the specifications for the project, developed the process by which the data would be transferred, fully tested the data transfer, and executed the go-live once all data was correctly verified.

Other Opportunities for eClinicalWorks Data Transfer

Chances are, your practice must share and report data for a number of reasons, either for patient care or for operational or management needs. This could include:

  • Patient Communications System … eClinicalWorks data can be transferred to third party CRM software such as SalesForce to facilitate communication and trigger health reminders or other important information to your patients.
  • Third-Party Billing Companies … If you use an outsourced billing service, the smooth and efficient transfer of claims and patient billing is key to ensuring steady cash flow to your practice. Mi7 can facilitate the ongoing transfer and receipt of data between systems to support these efforts.
  • Patient Kiosks … There are many options for patient kiosks to allow quick and easy check-in to your office. Demographics and clinical information can be gathered in the waiting room freeing up your staff’s time entering that documentation.  Mi7 has facilitated several solutions allowing the correct data to be transferred to the correct location to and from eClinicalworks to support these types of solutions.
  • Hospital Rounding … When providing patient care in an location remote to your office, it is important to have the patient information you need and be able to record the correct financial information back in to your system for billing. Mi7 has worked with several third-party remote information and data collection vendors to facilitate the transfer of information to allow for remote data access and documentation.

These are just a few of the examples of the type of third-party solutions for which Mi7 could provide automated data transfer. You may have other needs in your practice based on your processes.

Regardless of your needs, and how simple or complex they may be, the Mi7 team has the knowledge and experience with eClinicalWorks to make automated data transfer possible. Where others have said no, we say yes! If you have an idea, or perhaps even a challenge you’re trying to overcome and just don’t know where to start, reach out to us. We can help you develop a solution that will create efficiencies in your practice and add to your bottom line.

eClinicalWorks EMR Data Automation and Transformation

How many times have you thought: “surely there’s a way to get to that data from eClinicalWorks and make it useful,” or “there must be a way to automate this manual and repetitive data entry we are doing.”  Chances are, it’s crossed your mind on more than one occasion. Mi7 has just the solution. We are experts at not just data extraction, but also at data manipulation, transformation, and reporting, putting custom business logic in place and leveraging the information to automate processes while increasing efficiency and accountability across your organization.

Following are just a few examples of solutions we’ve implemented for practices around the country:

Automated Coding in eClinicalWorks

We all know how important it is to properly code various encounters, diagnoses, and results within a patient file. Most of the time, this work is performed manually by a staff member who reviews each encounter and puts the codes on the claim. This is time consuming and it opens the process up to human error – which results in a delay in reimbursement for the work you’ve performed. This can also cause additional time requirements for your staff, that could be better spent providing patient care. We can help you change all of this with automated coding. The Mi7 Solution:

  • We develop custom business logic to automate and execute a database review of each encounter. The data is in eClinicalWorks EMR, but the system itself cannot address this logic, so it relies on the external logic we develop to do what needs to be done.
  • The review runs on a nightly basis, scanning all encounters for that day.
  • The scan looks for certain quality items in the clinical documentation, such as specific diagnoses, lab results, or medications prescribed.
  • The process automatically adds the appropriate code to the encounter.

You get the code entry you need, performed in the most efficient, accurate, and timely manner possible, speeding up your reimbursement cycle and freeing up your staff to perform other duties. And, you are able to review the information involved in the quality reporting for PQRS, MIPS, or other initiatives.

eClinicalWorks Automated Referral Documentation and Closing

The majority of your patients likely have a team of providers covering different specialties based on their needs, and they may rely on your referrals to get them the care they need. There is documentation and a closing process required for referrals, but again, it’s typically manual and may not be performed in the timeliest manner. We can automate this:

  • Business logic is developed to automate and execute a database review of all open referrals in your system.
  • If the scan detects that a note has been sent back from the provider to whom the patient has been referred, the process marks the case as closed.
  • If a referral is a certain number of days old (90, 180, or whatever your practice deems appropriate), it is automatically marked closed, or brought to the attention of the appropriate staff person.

This process can help keep your eClinicalWorks up-to-date and free from clutter.

Lab Review Escalation

If you’re like many providers, you get hundreds of lab results every day. While most of them may be routine (and not urgent), there are some that require quick attention. How can you know how to prioritize your review time and give your immediate attention for situations that may be life threatening? Mi7 can implement an automation process for that.

  • Create custom business logic to identify key entries in the patient records and compare them to the most recent lab result.
  • Develop indicators to flag situations – such as high blood sugar levels for diabetic patients – that are serious and in need of attention.
  • Perform database scans throughout the day (for example, once per hour), to reprioritize your review list. Higher urgency results needing quick review are moved up the list and displayed accordingly when you log in.

This automated process helps to ensure you’re quickly addressing patients in need, and results in better patient population health management.

Do we have your mind exploring other items you might be able to automate yet? We hope so! It’s our goal at Mi7 to provide you with solutions that will help you operate more efficiently, enhance your patient care, elevate the patient experience, and appropriately manage items that can impact your ability to get paid in a timely manner. The Mi7 team has many years of experience serving practices, hospitals and physicians’ organizations of all sizes, and we can help you too. Contact us today to learn about the many data automation and transformation options that can take your practice to the next level.

 

 

Preparing for Discreet Data Extraction

All great initiatives start with a plan, a great deal of soul searching about exactly what it is you are trying to accomplish, and what you have at your disposal to work with. The process of discreet data extraction from your electronic health records system is no different. Having a plan and knowing what you have – and where you’re going – are critical. We at Mi7 have compiled a list of tips and things to consider as you prepare for your data extraction project:

  1. Do you have current processes in place for capturing your data?

Before we begin any extraction of data, it’s important that we know what processes you currently follow, and if your providers have guidelines for how data is entered. This will help us determine how clean and useful your data is, and what considerations we’ll need to account for as we plan for the extraction. For example, if there is no process in place to guide a provider to type in “ten” versus “10” into a data field, that inconsistent data will mean nothing to the system (the new one or the existing one), and will make mapping the data between system more challenging.

  1. How will you be using your data once extracted?

There are many reasons for extracting discreet data. You may be importing it into a new EHR, or archiving it. Regardless, your data extraction and the output we provide will be tailored for your specific needs. We’ll either prepare it for useful import into your new system, or provide easily searchable PDF documentation that can be used for archival purposes.

  1. What third-party systems will you need to integrate with?

This is important to know as we prepare your data to be useful in a new EMR environment. For example, if you are routinely interfacing with lab devices, we know that those devices like to receive data in more numeric format versus text.

  1. Will you be consolidating multiple systems?

Preparing to consolidate multiple systems requires a bit more thought and preparation, especially when identifying which fields will be migrated and the names of those fields. For example, “Are you a smoker” is a common piece of information to capture in your EMR. However, the field may be named something different across multiple systems. We’ll help you identify these fields and develop a plan to match them up.

  1. How do you want to view your data in the new system?

If you are moving to a new system, you have a choice of how you will see your data in the new system.  However, the detail to which you would like to view the data will affect the cost of the data extraction and import.  You can decide to simply have a summary document created that can be referred to when a new patient is documented in the new system.  Alternatively, you can decide to have individual discrete data point transferred over to the system.  We can assist you in discussion the costs and benefits of each option.

No matter your reasons for extracting discreet data, making sure the data is clean and consistent is the best way to prepare. If you need a discreet data extraction, contact Mi7 today! We have extensive experience, and can create custom solutions to fit your needs.

Quality Reporting

Are you struggling to get the data you need from eClinicalWorks? Whether you are a practice or a third-party vendor, it’s become essential to export data for quality reporting. Programs like CPC+, MIPS and MACRA have measures practices have to follow and for which data needs to be reported. Quality reporting helps practices get a better view of how they’re doing against the measures, and it can be frustrating when the data is difficult to retrieve.

There are hundreds of measures for patients that practices can record, but practices typically report 15-30 measures, sometimes more. Measures practices take for patient care can include:

  • Depression screening
  • Allergies
  • Diabetes
  • Hypertension
  • Labs
  • Tests
  • Personal measures

How Else is Quality Reporting Used?

Governmental reporting programs aren’t the only programs that want to see quality reporting though. Insurance companies use the data from quality reporting for patient population management. Major insurance provider in many states have started asking all of the practices they serve for this data. Having diagnoses for an entire geographical region in one database can be extremely useful for insurance companies. They can then monitor population health, determine what percentage of the population have certain conditions.

At Mi7, we’ve been doing these sorts of exports for over ten years. We extract and translate data into a format that is compatible for import into a common database. Quality reporting is important to ensure diseases are under control. They also help track what treatments are most successful, and whether or not a provider is fulfilling their roll to help patients control chronic diseases.

What’s the difference between exporting and reporting in this case? From the governmental standpoint, it’s the same thing in this case. Once exported, the data may first go to an Account of Care Organization (ACO) which completes the quality reporting.

While eClinicalWorks does have some of this capability, third-party management can sometimes provide a clearer view of what’s really happening.

How Quality Reporting Benefits You

While gathering and reporting quality data can sometimes seem difficult and time consuming, quality reporting can easily segue into a better overview of your own population’s health. Not only does this benefit your patients, it can benefit your organizations revenue stream as well. For instance, you could contact every female patient you have over 40 reminding them to have a mammogram. This not only improves their health, it also potentially increases your practices finances. Instead of using the data reactively, you can use it proactively. There’s no reason why focusing on care can’t also mean profitable business practices.

Quality reporting is more than just complying with government regulations; it’s about improving the lives of your patients, and improving the way you do business. If you need help with your quality reporting, Mi7 can help. Contact us today.

Associated vs. Unassociated

You went into healthcare to help people, who knew there’d be so many reports? Electronic health records can be a beast to sort through, which is why Mi7 is here to make sense of what you need to know. Today, we’ll be going over associated vs. unassociated when it comes to running reports. eClinicalWorks uses these terms in many of their standard reports. Without an understanding of what they mean, it can cause much confusion when trying to compare the various reports.

When you run a report for a month, you have options for what payments you want to see included in the report: the associated or the unassociated payment.

Unassociated payments are all of the payments you have received within a certain date range. This means that all payment received within the date range will be included for any charges for any dates, not necessarily for the dates of service specified in the report. So, some of those payments may be associated with previous date ranges.

When you select associated payments, it will only show the payments that are associated with charges entered in the selected date range. This can help you see if you want to see payments just on the services for the selected date range.

As you can imagine, associated vs. unassociated amounts can be very different. Which you choose can be dependent on how your accounting team wants to see and recognize revenue. Most people prefer to see all of the money that comes in for the date range. However, for reporting it can be helpful to keep track of which payments are associated with that billing period.

At Mi7, we have years of experience with eClinicalWorks reporting, and can assist you with your reporting needs, including custom logic for reports tailored just for your practice and what your accounting team would like to see. To learn more, contact us today!

eBO Output

eClinicalWorks is a great tool for many practices, but we have also had many practices come to us feeling lost after encountering issues with extracting data for various purposes. When eClinicalWorks hosts your EMR for you, it can be difficult to extract data in a way that allows for reporting to government agencies, sharing with ACO or other quality reporting organizations or sharing with other third-parties. Thankfully, you’re not out of luck. Even if it feels like you’ve hit a wall, Mi7 is here to provide you options, just like we’ve done for our clients for years.

Mi7 has experience working with eClinicalWorks-hosted practices pulling data, and even providing some automation of those reports and extracted data. We have had clients come to us who have struggled attempting to get the data they need for several months, only to have us find a solution within a month, or less.

When we create these reports, we customize the report to produce the data that is needed in the desired format.  We also provide a way to view the data in a readable format before extraction. Often data is difficult to read, but we format it in an easy-to-read manner so you know what you are exporting.

eClinicalWorks Hosted

eClinicalWorks database and host servers cannot be accessed natively on their Cloud server. When eClinicalWorks hosts data, they will not allow access directly to the database, which can cause major headaches for many practices. Having the ability to share data with a third party is often essential to their workflow, whether in dealing with patient clinical, practice management or billing information.  eClinicalWorks does not natively allow this access.

Mi7 uses eBO, the native application in eCW for reporting, to extract data from eClinicalWorks-hosted practices. This report can be scheduled to run on a periodic basis.  The report can then be exported to a file and shared by the client to a 3rd party if needed.

Custom extract reports in eBO can be used to access any data that is available in you eCW database.  With Mi7’s long history and experience in working the eClinicalworks data, we can typically provide everything that is needed even if it is not available in the eBO metadata.

This is useful for various purposes, like leveraging your data for:

  • Insurance companies
  • Appointment follow-ups or reminder systems
  • Customer surveys
  • Quality Reporting
  • 3rd Party Patient Payment solutions.

Hosted Locally

If you eCW database is hosted locally, or with another 3rd party hosting solution.  Mi7 can provide many other options for extracting data as well.  With direct database access there are additional options for automation.  Thereby allowing the staff at the practice to become more efficient and focus more on patient care.

Mi7 can simplify the process in the practice and do it fast and efficient way. Clients who have used our services once, typically come back to us for the rest of their reporting needs. Let us help you too, contact Mi7 today!

DO, a deer, Oh dear. Get the Whole Story on Your IT Needs

And other things you say when you don’t get the full story up front.

I like to think myself a quality musician.  I aspire to someday be a professional musician.  I am of the garden band geek variety: tuba.  I am also trying to expand my coolness through electric and upright bass.  In my pursuit of becoming a professional musician, I try to do the right things.  I practice several times a week, hopefully daily.  I run exercises to strengthen not only my playing ability, but to sight read music.

If you do not sight read music, sight reading is somewhat akin to reading ahead in a book or reading a recipe ahead while cooking.  It is the process of reading notes ahead of playing them.  As you get stronger in your sight reading skills, you read further ahead in the music and play from memory.  To me, an important part of sight reading is to review the music prior to playing.  Before I play a piece, I like to circle all of the important structural parts of the music: key signatures (especially changes), repeats (including signs and codas), large changes in volume (especially loud to soft) , etc.  I also like to review passages that may be difficult.  These things together give me a road map of the music and I can add additional visual queues to make the most of piece when I rehearse or perform.

Besides having many other life implications, I think this is also extremely important in the IT profession.  If we take the time to understand the road map, we can make smarter decisions about the different steps we take to get to the end goal.  Too often we are given pieces of information, but not the whole map.  Too many times business leaders think it unnecessary to involve IT in discussions of major business systems and process changes that affect systems.  I would go a step further and suggest that a good IT professional can not only provide valuable insight to system related issues, but also business and business process discussions.  IT professionals are engineers.  They take in information and devise solutions to problems.  There is no need for a system solution to every business challenge, but the method of analyzing information brought to the team by a IT professional can assist in finding the proper solution to the business challenge, whether process or system.

Over the years, we have had clients that have had us work on many different projects without giving us the whole story about what they are trying to do as a whole.  We had one client in particular that will pick systems to integrate and pick a different one a year or two later with the same purpose.  Many of these systems have different integration strategies, so much of the work must be redone.  It was only after we were included in more conversations about all of their business system challenges and priorities were we able to come up with a clear roadmap for phased implementation of different technologies that meet their longer term needs.

I realize that we (IT professionals) have caused some of this exclusion from the higher level business conversations, but we need to work on hearing and LISTENING to the whole problem before turning on our laser focus to fix the minute problem and focus on the larger picture.  Ask the bigger questions like “What is our bigger goal?” and “What are we trying to do?”  Once you ask the question, shut your pie hole and listen to the response.  Try not to be thinking of solutions while you listen to the response….so that you can truly LISTEN. Ask follow-up questions to understand the response.

As we continue to listen and ask the necessary questions, we prove to business leaders that IT professionals are important participants in the strategic business conversation.  At least that is one of my daily goals: participate in the conversation.   It’s important to understand where you’re going when playing a little DO-RE-MI.

And now that the hills are alive with the sound of … something … you may be ready to start talking (or singing) about your system integration strategies. Sight read the music so you know where you’re going, sing the whole song, and sing it to the people who need to hear it. That’s us! We’re your IT pros when it comes to electronic health records and integrating it with lab devices, other systems, and more.

Pump Up Your Jam (and your EHR Reporting)

A few weeks ago I finally got the motivation up to get our bikes ready to ride. The tires were completely flat. I started to pump up the tires with a little hand pump I have, but it takes several hundred pumps to inflate a tire to 55 lbs. I admit, I didn’t actually inflate the first tire all the way with the hand pump. After I had pumped 300 times and I only had about 20 lbs, I decided I needed some assistance. The next time I was at the department store with the name that means the same as “destination”, I took a look at their electric pumps. I reviewed all of the choices and decided on one that you plug into a wall outlet instead of a car 12V outlet. This will give us the most flexibility if we need to inflate a car tire, inflatable pool toys, etc.

I’m so excited to get the pump home so I can air up the tires and possibly go for a bike ride! I unpack the pump and look for the power cable. There is none. I read the box again. It doesn’t list any requirements. One line in the features section of the box says that it will connect to any extension cord. I guess this was the manufacturer’s way of saying that you need an extension cord to plug it in. I box it back up and put it on the shelf.

The next day I go to one of the big home improvement stores. I pick up an extension cord. The ends are connected together, but it looks like a three prong extension cord. When I get home, I take the pump out of the box, I unwrap the extension cord, unplug the ends… and it is a two prong extension cord! ARRRGGGHHH!

Well, I loathe going shopping, especially to the big home improvement stores, so I wait another day or two before going back to exchange the extension cord. When I do go back, I find the extension cords and unplug the ends to make sure that I get a three pronged extension cord this time.

Has this ever happened to you? I still maintain that the first problem with the pump was just clarity of packaging. How was I supposed to know that I needed an extension cord to plug something in? I confess to the second problem with the extension cord. I should have looked more closely to make sure I was getting what I needed. I didn’t realize that extension cords still came in two prong. My bad. In the end, I got the bike tires pumped up, but it took much longer to get it done with more than one trip to one of my favorite places on earth.

What’s the point? We see this regularly with clients and reports. Many clients are looking to analyze and use their data to better their business, but some have not committed to making the business changes to capture the data in a way that is usable for analysis. They just don’t have what they need to do the analysis.

We built a very complex quality report a while ago for a customer. This report had 15-20 quality metrics that were each dependent upon multiple pieces of data. You had to have this diagnosis group, have this lab, this Rx group, and data filled in the preventative medicine of the progress note for that day or in a note in the last 12 months. All of the quality metrics were that way. When we were scoping the report, we were very specific, with screen shots, about where the data will be captured, what specific data values we would count, and what the timeframe was for each metric. We set a timeframe that the providers had to complete their notes after the service date. We would then daily run the metrics for an appointment X days after the service date.

We went through testing. We modified some of the metrics. We did more testing. Then, when the client was satisfied, we installed the report on the users’ computers that needed it and told them to start running the report. Well, that would have been great…if what we were reporting was already how ALL of the providers were documenting. We had a call about once a week for the next couple of months researching issues with the report. All of them ended up not being the report, but the data that had been entered.

When you invest the time and money to come up with reports and other ways to analyze and make the best use of your data, you must make sure to educate the users to enter the data in the system in a way that you can analyze. You must insert controls that help you catch data entry or process issues. You can build the most awesome report or analytics in the world, but if you don’t have reliable data entry and a way to catch your data issues, the report is going to provide you incorrect results.

Admit it. You’re now ready to “Pump Up Your Jam” when it comes to your EMR reporting needs. And you probably have that song from the 90s running through your head too. You’re welcome. Mi7 is the pump to your jam, working with you to define the key metrics for your medical practice and come up with a way to track and report on that data. But it doesn’t end with the pump and the jam. Mi7 can also help you build the analytic reports to catch issues related to patient data, billing reports, efficiency and more to keep the business side of your practice on track.

Contact us today to discuss your EHR reporting needs.

Feelin’ Lucky With Your Data Migration or Integration Project?

My wife and I recently went to the home of Ernest Hemingway in Key West. Learning about the history of the house and some of the background of the books by Mr. Hemingway, I decided to read some of Mr. Hemingway’s work. I started with The Old Man and The Sea.

For those of you who have not read this wonderful, short, piece of literature, I won’t ruin the story for you. I will just give you a synopsis of the story here so we can get to the point.

The story is located in and off the shores of Cuba (also Mr. Hemingway’s origin). There was an old man. He was a fisherman. He hadn’t had much luck with the fish lately. One day he went out alone on his small fishing boat. There is one quote that I want to focus on for this blog. The old man says it to himself several hours after he set out on the boat.

“Every day is a new day. It is better to be lucky. But I would rather be exact. Then when luck comes you are ready.”

I think this quote especially applies to system testing. In the “Magic!” blog, we discussed the process of integration projects:

Vendors involved in implementation of an interface usually do roundtrip testing (to verify communication) and basic test cases. The responsibility for the more rigorous testing typically falls to the client. This is what is called user testing. The client needs to outline the different business scenarios that the interface was designed to solve and develop test cases that will verify all of the business scenarios. Make sure you devote ample time to testing. It will save you headaches in the long run.

Let’s break this down further.

What is roundtrip testing? For each type of message (demographics/ADT, scheduling/SIU, charge/DFT, etc), the sending side of an interface will send a message. The receiving side will verify receipt and verify the message is formatted as expected (see “Standard is not so Standard” for more discussion of setting expectations). Note that this is more to confirm that the two systems are talking rather than to verify any sort of business logic.

Why do most vendors only do roundtrip testing? Most vendors will not know the workflow intricacies of a practice. The vendor knows what is in the specification document for the integration. They can test what is outlined in the specification, but what is outline in the specification does not necessarily encompass all variations in workflow practice encounters, especially rare scenarios. The vendor relies on the practice to know their workflow and to understand the different scenarios that need to be tested in the integration. This is not always the case. For example, the practice may have a couple patients that come in once or twice a year. These patients are special cases and the practice may need to have a special workflow in their system for these two patients when they visit. An integration built for the standard use case that covers 95% of all encounters may not properly handle the special cases in your practice.

It is the practice’s responsibility to identify these special use cases and test for them. When I discuss testing with a client I ask them to first describe the typical workflow. For example, we have a client that implemented a demographics interface from an associated hospital. The typical workflow for a patient that doesn’t exist in their system is to add the patient, add the guarantor, and add the patient insurance. The typical workflow for a patient that does exist matched on account number, first name, last name, and date of birth is to just update demographic information, leave the guarantor as is, document the patient insurance in the demographic notes, but don’t update the patient insurance on the patient.

Once you have described the typical workflow, start going through the possible variations of the workflow. You need to include knowledgeable people from all departments that are affected by the interface to catch the possible different scenarios. In our example, as we were testing, we found a special scenario where a patient was admitted to the hospital ER, but the new account entered in the hospital system had a temporary patient name. Well, this prompted a message across the interface with the temporary name. This name was entered in the receiving system side as a new patient. When the name was updated, we got a mismatch because the account number matched, but the patient name and date of birth did not. This prompted us to change the scope and logic of the interface on receiving side to discard patients with certain specified names and departments. Once all of the information was filled out, we would then enter the patient on the receiving side.

It is always better to understand these different scenarios when you are scoping out the integration project, but if the practice does not catch the scenario in testing, it can cause bigger data issues in production. In the example, not testing all of the scenarios could have resulted in lots of incorrectly entered and mismatched patients when the interface was put into production.

Another important point with testing is to test everything every time there is a revision. If you caught an error in one of your testing scenarios, make sure to test every step in all of your scenarios again when the error is resolved by the interface vendor. There have been many times when I am testing for a client that when the vendor fixes one thing it breaks something else. The fix had unintended impact on a different part of the integration process. Start from the beginning. Test every scenario thoroughly with every revision. You may even find that other scenarios come up when you find an error that you need to test specifically to make sure the previous error does not rear its ugly head again.

A practice should realize the system is theirs. Accepting what happens to you after the fact is never a good position to take. The practice is the last line of defense before a system or interface is implemented that could benefit or harm the practice. Test it. Understand it. Even if project scope needs to change, it is best to catch an issue up front before your practice is reliant on the system and has to implement work-arounds to accomplish their goal. You may realize that it costs more in the long run to allow things to happen without testing than to put the effort in up front and make the system work as you need it. As the quote said, you might get lucky, but it is better to be exact. It is better to be prepared. Then you will be ready if you are lucky.

Is your practice planning a data migration or integration project, and relying on luck to get you through it? Don’t do it! Luck will only get you so far. It will probably not catch you a fish, and most certainly won’t lead to a successful data migration for your medical practice or physician organization. Migrating data from one electronic health records system to the next takes careful planning and testing. Rely on the data migration gurus at Mi7 to put you on the right path. We’re not lucky, we’re exact. And that’s the way (uh-huh uh-huh) we like it (uh-huh uh-huh).

Cat Scratch Fever and Your EHR Interface

We got a couple of kittens a few months ago. We like to take them with us when we travel. Believe it or not, they are great travelers. If you have ever raised a kitten, you know that there are times that you need to remind them of where the litter box is, especially if you haven’t been in this place in a while and the litter box is not visible to them. We keep our litter boxes in the storage room in the basement, so it is out sight, and hopefully out of smell, so it is definitely not visible. Thing is, when they can’t find the litter box, they try to tell you in whatever way they can.

One evening, the day after we had just returned home after a trip, one of the kittens, Olive, was very vocal. We thought nothing of it since she sometimes yells at the bugs on the window. When we went to bed, she seemed very playful. She likes to get up on our bed and slide or scratch and slide. It is all very cute, but she was scratching and was more vocal on that particular night. I get into bed and my wife is playing with Olive. Olive starts pawing at my knee and sits. She then starts crapping on my knee (I’m under the covers)! I don’t realize it immediately and my wife starts yelling “She’s crapping on your knee!” She grabs Olive and takes her downstairs to the litter box. I’m left with a big pile of crap on the bedspread on my knee. It looked like she had been holding it for at least a day.

We learned a couple of things with this poop adventure:

  • When you are in a new place, take your cat to the litter box a few times a day.
  • Pay attention to someone trying tell you something.

Now I’m going to tie this experience back into interfaces, so bear with me. Just like the work is never over when it comes to making sure my cats know where the litter box is, your work with your interface is not over when you have gone through the implementation process, testing, and you are now live with the interface. Now, it’s time to listen to it.

All interfaces have some sort of log or reconciliation process to handle errors. Many practices do not pay attention interface logs. Sometimes they don’t know they need to, don’t understand the logs, or just don’t want to. In any case, this is a recipe for trouble.

Before implementing an interface, practices should find out what is expected of them long term. Many practices ask about ongoing maintenance and support costs, but they do not ask about human resource requirements to manage the day to day processes of an interface. Make sure to get this information and plan for the resource requirements.

First, identify the person within the practice who will be managing the interface on a daily basis. This person should be involved in the testing process, and the practice needs to take ownership of the testing process. This interface is going to be part of your business process after it is implemented. The practice needs to understand the impact of the interface on the business. Too often practices learn about the interface weeks after the go-live. The time to test and determine the majority of different possible scenarios is during implementation and testing, not after go-live. It is also during this timeframe that potential issues and resolutions in daily use of the interface should be identified and documented along with resolutions and escalation procedures. This document should be used as your standard operation procedure manual for the interface.

After go-live, this interface standard operation procedure manual should be followed, regularly reviewed, and revised as necessary to keep the manual up to date. Part of this manual is the regular review of logs and reconciliation of messages and results. It is through these tools that a practice can catch issues with the interface or scenarios that were not originally scoped in the interface.

The dangers of not having this manual, and listening to what your interface is telling you, can be as devastating as me not listening to my cat. For example, we at Mi7 have a client that uses our HL7 DFT interface. Once a year, when new CPT’s come out, we get a call about a week later stating that the interface is not working. This has gone on for a few years now. The issue is that the new CPT is in the PM system, but had not yet been added to the fee schedule by the practice. The interface only adds CPT’s that have been added to the specified fee schedule. If the practice had been reconciling messages and reviewing the logs, they would have noticed errors adding this specific CPT to the claim. Well, the practice had some turn over in the past year, and the person that previously had been trained to review this particular issue last year was no longer there. Wouldn’t it have been nice if the previous person had given the new person their interface procedure manual?

Oh, and developers are sometimes human. We have had instances where practices that have done their daily reconciliation have found issues with the interface that should have been found in testing, or they’ve found new scenarios that were not originally scoped. For example, billing procedures can regularly change, and therefore, new scenarios always come up that need to be handled by these interfaces. Only by reviewing logs and reconciling can a practice be sure that an interface continues to properly support a business process. If you are not getting the logging needed to support your interface, have the interface developer add it. Remember that computers do what you tell them. It is your interface. Own it. Make sure it works for you.

Are you listening to your interface? We hope this story about Olive and her pile of crap has inspired you to do so. After all, your interface is probably managing many things in your medical practice, and your electronic health records system. Listen to your lab device interface. Pay attention to what your billing interface is telling you. Take heed when your custom interface puts up a red flag. Failure to do so could mean that you end up with a big pile of crap on your leg.

Contact us, we can teach you how to listen.