Archive for Blogs – Page 2

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.

Pass the Tofurkey and a Custom EHR Report

Well, I was going to write some witty story about using the right tool for the job, but, with all of the recent election talk, I figure we’ve had enough of that topic. So let’s get into the brisket (no not BREXIT!) ‐ meat, or Tofurkey if you prefer…

Reporting can be a challenging topic for anyone that uses, implements or supports reports. The key to understanding reports is to realize that any report you review is built for a specific person for a specific reason at a specific time. That person was trying to answer a specific question, so they built this report.

There are reports that have been developed to be used by the general user, but each general, or “canned”, report is still developed to answer a specific set of questions. This means that using a general report to answer questions for which the report was not designed may give you the wrong answer to the question you are trying to answer. This is why whenever someone is looking for a general report to answer a specific question, the question, business workflow, and variations to the question and workflow need to be reviewed to make sure that the right report is used to answer the specific question asked.

When I talk to different users about reports, I don’t start with an existing report. I always start with the question the user is trying to answer. I ask as many questions I can think of to try to understand what the user is trying to do. Many times I ask the same questions a different way to make sure that I completely understand.

I then get into the process. I look at the business process as a whole, including the system and non‐system parts of the process. Of course writing a custom ehr report from a system requires the data to be in the system, but you would be surprised to hear that many times the data the user wants to report is not currently captured in the system or it is captured in a way that is not reportable. It is only through understanding the business process as a whole that you can identify the restraints of report and the business process changes that might be necessary to properly answer the user’s question with a system report.

Once I understand the question and the process, I detail out the details of the report. There are five major categories of report details: logic, user selected filters, fields, report field to system mapping, field groupings, and report delivery.

Here are the various questions I ask, and items we consider when going through this process:

  • Logic ‐ Describe what conditions the data must meet in order to show or to be excluded from the report. For example, I only want patients with appointments in the selected timeframe that do not have a current, valid referral.
  • User Selected Filters ‐ List the filters that should be on a prompt page. In the example given above, you would have a “From Appointment Date” and a “To Appointment Date”. You might have an “Appointment Provider” filter if the user wanted to filter by appointment provider.
  • Fields – List the fields that the user wants on the report. For the example above, you might have the patient name, date of birth, appointment date, appointment time, appointment provider, and primary insurance.
  • Report Field to System Mapping ‐ List where each of the report fields listed above comes from the system. I find it beneficial to not only include the screen and field name in a table with the report field, but also include screen shots of the different fields.
  • Field Groupings ‐ Fields in the field list by which the user wants to group data on the report. This is typically for formatting, improving readability, or subtotals. In the example above, you might group by appointment provider or date.
  • Report Delivery ‐ It is important to understand what the user wants to do with the report. Do they want to download the data to CSV or Excel? Do they want a formatted report they can export to PDF and email? Do they want to automatically upload the data to a third party like an ACO, 340B vendor, or similar? Depending on the delivery method, you may need to change the tool you use to build the custom ehr report.

As you can see, there is a lot to consider when developing an ehr custom report. If you are looking at using a canned report, don’t just assume that because the title of a report sounds like what you are looking for that it is. Take a step back to look at what questions you are asking, what the business and system processes are, and then review the report to determine if it meets your needs.

Remember this Thanksgiving that sometimes homemade cranberry sauce may be what you think you want, but sometimes you just need a quality can of cranberry gelatin. Either way, give thanks for all your blessings, including the report developer that just completed the 20th revision of your report because you didn’t know what you really wanted when you started. I know they will be thankful for you!

Need a report, canned Spam for the holidays, or just not quite sure how to use all of the “ingredients” that make up your EHR system? Mi7 can mix it all up, cook it, and help you dish up a custom ehr report that your entire practice will enjoy. Want a custom ehr report that will help you better manage certain patient populations? Coming right up! Need to know the primary reasons your claims are being rejected, or where hang ups in the billing process might be? BAM! We can do that too.

Contact us today, we’d like to hear what questions you need answered.

What Would MacGyver Do?

Sometimes you just have to “MacGyver” a situation. I find that to be true in pretty much every aspect of life, whether I’m working on a medical data integration project or something closer to home.

While moving into a house that was new (to us), we unpacked several boxes of dishes and put them in the dishwasher that was several years old. We loaded up the bottom tray and had the majority of the top tray loaded when it happened. Three of the four wheels that suspend the top tray in the dishwasher fell off. Luckily, my wife caught the side that fell off completely until I could grab it and we could unload the tray.

I spent several minutes thinking “CRAP! We’re just moving in and stuff is already falling apart.” I accept the fact that unexpected expenses show up, and sometimes at the worst time. I’ll have more to say about that in another post. What I want to focus on now, is how you react to things that happen around you.

In this instance, our options were limited. It was late, we didn’t have many tools, and we couldn’t fabricate new plastic wheels. I was going to have to “MacGyver” a solution. Do we have gum and a paperclip? (What MacGyver always seemed to use to get out of a precarious situation.) No. What we did find was a bundle of twist ties. I grabbed three of the longest ones and attached the wheels back on the tray. A little weight test, and it seemed to work. We put some dishes in the tray and it still held. We ran the dishwasher and didn’t hear any big crashes. Everything seemed to work.

In this case, I took a little time for some self pity and panic. But that really didn’t get me anywhere. You have to get up, dust your wheels off, assess the situation, and engineer a solution that works in that moment.

In the world of EMR integration, we get involved in many conversations where the prospective client has already been told that there is no solution to their business challenge. Sometimes they’ve been told that more than once. Most of the time it is an EMR vendor that is not willing to customize an integration solution to meet or even understand their requirement. I know that unique solutions can greatly hinder supportability across thousands of clients. But if the client cannot succeed using a particular application, they will eventually find a software solution that will better facilitate their business.

We just finished up an integration project for a client that had already been told that what they wanted couldn’t be done. They need an outbound diagnostic imaging orders interface to a PACS system. That’s not all that unique. What is unique about their requirement is the return inbound results. The inbound messages either get routed as transcription, populating different sections of an existing progress note or back to the order notes, depending on a value in the HL7 message.

Don’t get me wrong. There are times when there are too many barriers to engineer a proper solution, but dismissing the challenge before you open your mind to the possibilities does not serve you or your client. Think of related activities that can be done. How are those activities related? Can you string a set of related activities together to get the desired outcome? A little creative thinking can go a long way to creating a pretty crafty solution.

Were you looking for an article on EHR integration, or for a crack team of wizards who can work wonders? Either way, you’re in luck. You’ve found both. Mi7 offers top-tier services related to medical data and making the best use of it. Don’t let anyone tell you it’s impossible until you talk with us.

The Wheels on the Bus Go ‘Round

We were driving from St. Louis to Chicago on a Sunday afternoon for an appointment Monday morning.  When we were about an hour and a half outside of Chicago, our tire blew.  We were close to an exit, so I pulled off the highway and into a truck stop to assess the situation.  We have these run flat tires that allow you to go 50 miles at 50 mph.  We had more than 50 miles to go to our destination and I didn’t feel comfortable driving 50 mph on an interstate where people were going 80+ mph, so I assessed the situation. 

We needed a new tire.  Can we get a new tire somewhere close? Nope.  Many of the tire stores in the area were closed since it was late Sunday afternoon.  The big tire stores (Walmart and Sears) didn’t carry the tire we needed and would have to order it.  We had to be towed to the dealer in Chicago, so I called roadside assist.

I had two passengers with me, so I knew that riding in a standard tow truck was not going to work.  I requested a tow with 3 passenger ride along. I was given a 2 hour ETA.  I got a call from the contracted towing company about 40 minutes later.  I confirmed that there was room for 3 passengers.  Unfortunately, this was not communicated to the towing contractor, so the truck that was in the area did not have the room for 3 passengers.  This prompted another call to roadside assist and a new towing company dispatched a truck for us.  

This is not the end of this story, but it is enough for this post.  I relay this story because sometimes things get lost in translation.  It’s like when you played telephone as a kid.  You tell someone something, they tell someone else and so on.  By the end, what is being said may not be the same as what you told the first person.  

How does this apply to healthcare technology?  Many practices have seen the value  of in-house lab and imaging equipment for their business.  They can offer these services internally instead of referring the patients out to other businesses.  The issue is that not all lab and imaging devices can speak the same language as the practice’s EMR.  Sometimes the devices only communicate via serial or network via ASTM,  ABX, or Argos.  Sometimes the EMR will only accept HL7.  Mi7 has developed the expertise to take the device languages and translate the data to HL7 or, in some EMR’s, write the data directly to the EMR.   With the government incentives and mandates to store discrete data (test results as individual values), practices have been printing out these results and manually entering them.  This can reduce employee productivity and introduce potential errors to the result transcription process.  

I have seen practices take the data from these machines and create proactive marketing (called “health maintenance” programs in the patient arena) campaigns to promote patient maintenance of A1C, Cholesterol, and other key chronic maintenance values.  This helps the practices pay for the device and improve overall patient health.

There are many types of devices that collect and report on data.  If you are paying for the device, why not use the data provided by the device to improve patient care and potentially grow your business? Use the devices you have.  Maximize the value of data collected by these devices. It’s your data. Use it.

Living With Your Head in the Cloud

I never really bought into the DIY craze. I know that many people enjoy fixing a sink or repairing their car, for example. I am not one of those people. I have a job where I know what I am doing and I am actually pretty good at it. I know that there are many other people out there who are just as good at their jobs as I am at mine. I also know that I am not very good at these other jobs, so I tend to hire people who not only know how to do their job, but they excel at it. This is especially true for me when it comes to home or auto repair/service. I like to think of it as stimulating the economy.

I am a growing believer of CLOUD services. The basic idea is to hire someone else to take care of your systems so that you can focus on your business. We have actually moved the majority of our systems to the cloud.

If you think it’s less expensive to do it yourself, think again. The true cost of the system is not much different than having the servers and applications in house. They take care of the backups, upgrades, and maintaining the servers. All you need is an internet connection. Spending your weekends upgrading servers and applications are now a thing of the past.

Recently, we were discussing an integration project with a prospect. After we had discussed the majority of the integration and how it was going to work, the prospect told us they were planning to move to the cloud within the next few months. We had worked with this system before and we knew that this cloud provider would not be able to provide the necessary access to the system to make it work. We shared this with the prospect and were able to offer another cloud provider that would be able to provide the access they needed.

Moving your business systems to the cloud is a MAJOR decision, and as with any major purchase, you should always do your research first. Not all cloud systems are created equal, so thorough research is crucial to ensuring that the one you choose will be able to provide you with everything you need.

Can you run custom reports and get the data you need to run your business? Can you continue to enhance your business process by integrating with systems outside of the cloud? Can you leave the cloud service if necessary? Will you get all of your data at a reasonable cost and in a reasonable time frame? Find the cloud system that will work best for you and your company.

Don’t let the cloud hold your data hostage. It’s your data. Use it.

Looking for an article on EMR data or related services? You’ve hit the jackpot here. By the way, if you need to bust your EMR data out of jail, Mi7 has the best crew around. We specialize in migrating data for hospitals and medical practices. Just don’t tell the cops.


My wife and I were driving to work this morning and the song “Magic” by PILOT came on the radio. We looked at each other and chuckled. We both work in the IT industry, providing solutions for medical practices. Our work with EMR systems and data integration requires specialized knowledge, making us look like magicians to our customers. Of course, it’s not magic at all. We follow a proven process and our customer is part of that process.

There are two types of customers out there.  The first type of customer is one who doesn’t care about the difficulty of the project or the time frame; they just want it to immediately be “magically” done.  The second type of customer realizes that the project really isn’t magic and that it actually takes a considerable amount of time and effort to make it seem like magic.

As with any project, the expectations you bring to the table are important. A successful integration project depends on our customer, no matter which type of customer they are, being involved in the business decisions from the beginning to go-live. They stay involved in the daily operation and support of the integration. I’m not saying that a doctor needs to support their own interface, but someone at the practice should monitor and reconcile messages daily to know if the interface worked that day and report any issues to support.

Let’s demystify data integration projects from the thousand foot view. Just like any development project, there are several steps.

  1. Scoping – Defining the requirements for the integration. This includes the business and system processes on both sides of the interface, data that will be sent and received, and how the data will be handled when received. It is important for the customer to be involved in this process so that they identify their business needs and know how the interface will work when completed.

  1. Development/Configuration – No matter if this is a “standard” HL7 interface or not, there is always development and/or configuration. Depending on how “custom” the business process is that the interface is facilitating, the development could potentially be more complex and take longer.  The customer may not be involved in the development, but the implementers may have questions about different scenarios and use cases, so it is important for the customer to stay engaged in the conversation.

  1. Testing – Vendors involved in implementation of an interface usually do round-trip 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 that each of the business scenarios is working as expected.  Make sure you devote ample time to testing; it will save you headaches in the long run.

  1. Go-live, On-going Reconciliation, and Support – Once the integration has been tested, it can be put into production. The work doesn’t stop once in production. The client needs to monitor the interface to make sure it continues running as expected and determine if any business scenarios that were not tested or new business scenarios are handled properly.  There will also likely be some data issues, like unmatched patients or encounters, that need to be handled through a reconciliation process. Of course if you have any questions or issues you cannot resolve with the tools provided, call your vendor for support.

These four steps are the basic highlights. The details differ from one practice to another, depending on the nature and scale of the project. I’ll devote some time later to each one of these sections individually.

But for now, remember these three things:

  • Be present.
  • Ask questions if you don’t understand.
  • It’s your system. Your data. Own it.

It’s magic, you know… Never believe it’s not so…

By the way, you may have been looking for an article on EHR integration services for hospitals and medical practices. In case you didn’t know it, this is it. I just didn’t feel like peppering it with fancy words and stuffy keywords.

If you can’t stand up, sit down! And cleaning up data migration messes.

For those who work and office (or live) with someone else, have you ever walked in the restroom and found that someone has left a mess on the floor? I’m not talking about the trash turned over, although that is ridiculous unless you have a pet that likes to turn over garbage. I’m talking unidentified fluids on the floor. Someone missed the giant hole that is the toilet. Now, granted, most of the time a male is the culprit. As males, every single one of us has had times where we point in one direction and it goes another. This is just a fact of life. The key is how you handle the mess.

This is another of those workplace metaphors. There are times that you make mistakes. There are times you create a mess. That’s going to happen. Maybe it’s not even “your fault.” In my 20 years in the IT industry, I have made my share of messes. The key character trait is how you respond to those messes: do you clean it up yourself or do you leave it for someone else?

Recently we received data from another EMR vendor from which one of our clients was moving. We had already migrated several different types of data, but when we got to the document migration, the data was a mess. Multipage documents were broken apart into single page documents and the document compression (these were TIFF’s) was not correct for the system to which we were migrating.

We typically require sample files before we quote a project, but the vendor providing the data made getting samples cost prohibitive for the client, so we went without a sample this time. This was a mess we needed to clean up without additional cost to the client. We ended up spending hundreds of hours of processing time to combine the single page documents into the appropriate multipage documents and re-compressing the documents into the proper format. It took much longer to process than the time we budgeted, but it was the right thing to do.

I know that no one person can have all of the skill sets to clean up all messes for all time. That is the reason we work with other people. We have a support network to help us with things that we don’t know how to do or can’t handle by ourselves.

The people I want to work with are people that recognize when they have made a mess. They clean up messes they can handle and call people when they need help. They don’t just leave the mess for someone else to find and clean up for them.

When you are working in the service industry (any industry really), you must be willing to admit to your mistakes and come up with a plan to correct them. The key to this process is, once again, COMMUNICATION. Communicate the issue and demonstrate that you understand the issue. Communicate that you own the issue, communicate the plan, communicate the status, communicate completion and communicate how you will prevent the issue from happening again. Customers will appreciate your admission of humanity and humility. They will appreciate your willingness to take charge of the situation and make things right. Above all, they will appreciate that they know what is happening because you have kept them informed with your proper communication.

Getting the best from your best of breed; Interoperability in healthcare

I am an audiophile. I love music. I am very particular about the quality of sound produced by audio equipment when listening to music or watching a movie or TV. Anyone who has done their research or compared audio systems knows that an electronics manufacturer typically specializes in one or two things. You don’t often get a high end stereo from the same manufacturer that you get your TV. If you want to have medium grade or better, you have to buy components from different manufacturers.

It’s no different with business systems, and it’s not a new idea. I recall systems in manufacturing and distribution in the 90’s. Many system vendors had built ancillary applications but the market eventually went to “best of breed.” Customers could then integrate the “best of breed” applications with their primary system to fill their needs.

Several EHR vendors have decided to build their own version of patient portals, kiosks, population health, mobile, and charge capture applications among others. Not only has this development taken away from their core expertise of building EHR solutions, but they have also taken the approach of “if it’s not our application, you can’t integrate it.”

This leaves the hospital or practice with an EHR’s ancillary application that is less than the best. There are companies that focus on specific types of applications: patient portals, referral networks, kiosks, etc. These companies make the best, most feature rich and user friendly products. But you can’t use them.

EHR companies have developed these ancillary applications to try to capture more of the client’s mindshare. It’s the right business move, but only when you don’t lose focus on why clients come to you in the first place. Developing a fiefdom is not what INTEROPERABILITY is about. It’s about sharing data, working with others and making patient care the best it can be. The ideas of a single company are not always the best for every practice.

The Healthcare software industry needs to get to the “best of breed” model. It is much more prevalent at the in-patient level, but the ambulatory space EHR vendors have not caught on yet. They tend to hold that integration hostage and limit the ability to do the integration necessary to make these “best of breed” applications work for the client.

I’m not saying that there won’t be some cost involved. There is work to be done and integration is not standardized enough to drive costs down at this point. But there is no reason to put the pricing beyond reach of a practice to deter them from implementing a “best of breed” application.

The practice needs to determine their needs and not let the EHR vendor determine their path. It is the practice’s business, their relationship with the patient, their money, and their data.

Take control of your systems and your data! You work with them every day and they can either aid you or hinder you!

Clean your dirty dishes! Interoperability, communication and customer satisfaction.

Every day there’s a scenario that plays out at my office. I go to the kitchen to get my coffee from our run-of-the-mill coffee maker. We don’t have one of those Keurig machines with a water line connection. The reservoir is always empty, so I have to add water. I take the reservoir off the machine and go to the water faucet. I then find that the sink is full of dishes. I can’t get the reservoir in the sink to fill it with water. This is what you might call one of my pet peeves.

At home I’m happy to be the dish washer. I find it therapeutic in a masochistic sort of way, but only at home. I don’t go to work to wash other peoples’ dishes! Most of the time I get the excuse that they’re letting the dishes “soak.” “Soaking” is just another form of procrastination.

Procrastination has its consequences in life and business, especially in the service and support industry. If you want to excel as a service and support company, some things are imperative. Most of them, besides delivering what you promised, are all centered around communication.

Tell the customer what you are going to do, when you are going to do it, the status of said thing to be done, and so on. Communicate when it is done and any issues, potential issues, and possible resolutions if they are necessary. Don’t get me wrong, this goes both ways. But communication from the service provider to the customer is always required. That is what the service provider is getting paid to do. It is the minimum amount of work to be done.

We find this especially in integration projects. Last year we were hired to provide the testing for an interface between a hospital lab system and practice EMR for billing. They had been working on this project for some time and we were brought in for testing towards the tail end of the project. While going through our testing plan we found that not all of the business scenarios were properly supported by the interface.

Once we identified this, we immediately notified the project team and sponsors concerning the issue. We then started working with the vendors on both sides of the interface to determine how this could be resolved. Once we had detail regarding the issue and options for resolution, we escalated the decision to the project sponsors to make the decision. The project sponsors were very appreciative of the regular communication and updates concerning the outstanding issues.

If you postpone (procrastinate) communication to a customer, you are not providing the best service and support possible. There are some situations where you might not want to give all of the information. Sometimes you don’t have the whole story. But you must let the customer to know that you are still working on the issue for them.

Lack of communication just leads to the customer making their own assumptions. Those assumptions over a period of time lead them to conclude that the service provider is not going to help them. Naturally, they start looking for someone who will service them better.

When in doubt, communicate. Communicate your questions. Communicate your status. Don’t procrastinate. Communicate.

Don’t get me started on the bathroom….