In healthcare, most data is exchanged electronically between partners via EDI (Electronic Data Interchange), and “Big Data” is helping the industry become more efficient and productive. EDI originated because it provided a structured mechanism for sharing data between disparate organizations and systems.

The more common means of transferring data from source to a data warehouse is ETL, but there are times when you might want to consider using ELT (see James Serra’s “Difference between ETL and ELT” or Daniel Harris’ “ETL vs. ELT: How to Choose the Best Approach for Your Data Warehouse”).

EDI allows the healthcare industry to bring in information needed to help perform analytics. However, in the past, the issue was being able to house all the information and easily retrieve it. There are still some issues with EDI regarding data quality, but that is getting better as each business is learning the need for reliable data to perform their analytics.

EHRs (Electronic Health Records) also play a big role in the ability to perform analytics, and there is an immense amount of raw data available in EHRs, EMRs (Electronic Medical Records) and EDI. “Big Data” now provides a greater opportunity to use this information to perform critical analytics by applying business intelligence techniques.

In the past, the EDI data went to a data warehouse. Now with “Big Data,” the industry is able to house and analyze the information for visibility and quality. When linked with the adjudication system, organizations can get a more complete view of what is happening in their business and deliver real-time analytics of clinical, financial, as well as fraud and HR.

Analytics allow for the examination of patterns to determine how care can be improved while reducing the need for repetitive hospital stays and limiting excessive spending for testings etc. This allows the healthcare industry to reduce fraud, waste, and abuse. “Big Data” allows them to store and go back in their data history to analyze large unstructured datasets to detect anomalies and patterns.

Stay tuned for “How EDI Relates to Cloud Computing.”

If you are doing EDI, at one time or another you have had to troubleshoot why your data is being rejected. This article deals with just a simple error received and how to find the solution. Sometimes it is easier than you think.

This particular error came as an XML message. I am only going to show those portions dealing with the error.

<ExecutionDate>Monday, October 01, 2012</ExecutionDate>

<ExecutionTime>03:00:29 PM (GMT)</ExecutionTime>

<AuditStatus>Failed</AuditStatus>

<NumberOfErrors>1</NumberOfErrors>

– <ErrorByCategory>

– <Category Name=”Rejecting“>

<Severity Name=”Normal“>1</Severity>

– <TransactionErrors>

– <Error Severity=”Normal” Category=”Rejecting” SNIP=”1” Index=”1” ID=”0xa1001a“>

<Brief>XEngine error.</Brief>

<Description>Not expected text ‘D8’ in position 5777.</Description>

– <ErrorObjectInfo>

<Parameter Name=”Param_1“>D8</Parameter>

<Parameter Name=”Param_2“>5777</Parameter>

What does this mean? Don’t panic, just take it one step at a time. This error message is stating that it found a DOB where it was not expected.

Next look at the data sent. Here is the sample data in error.

ISA*00* *00* *ZZ*SNDR *ZZ*RCVR *121001*1200*{*00501*747549179*0*P*^~
GS*HS*SNDR*SCRV*20121001*10002727*640141*X*005010X279A1~
ST*270*640142*005010X279A1~
BHT*0022*13*SubTransID*20121001*10002727~
HL*1**20*1~
NM1*PR*2*PAYER NAME*****PI*ID CODE~
HL*2*1*21*1~
NM1*1P*2*Provider Name*****XX*NPI Number~
REF*Q4*Prior ID Number~
HL*3*2*22*1~
NM1*IL*1*LName Subscriber*FName Subscriber****MI*Member ID~
REF*6P*Group Number~
DMG*D8*19010101~
HL*4*3*23*0~
NM1*03*1*LName Dependent*FName Dependent*MI Dependent~
DMG***F~
DTP*291*RD8*20121001-20121001~
EQ*30~
SE*17*640142~
GE*1*640141~
IEA*1*000640140~

If you compare your data to the HIPAA 270/271 5010 TR3 guide you will notice it states the DOB is required at the Subscriber level IF the Subscriber is the patient. In this case, the patient is the Dependent, and we now know that the DOB should be sent at the Dependent level.

NM1*IL*1*LName Subscriber*FName Subscriber****MI*Member ID~

REF*6P*Group Number~

DMG*D8*19010101~ – Should not be sent

HL*4*3*23*0~

NM1*03*1*LName Dependent*FName Dependent*MI Dependent~

DMG***F~ – Should be sent

Next you need to determine why your mapping did not populate correctly. That is another issue altogether. It may be an easy or complex problem to fix, but your mapping program should be the next step.

Simple, right? Unfortunately not all your errors will be as easy to determine. Remember, any EDI error can be found and resolved if you start with the small picture rather than the big picture.

The 2010 passage of the Patient Protection and Affordable Care Act (ACA) and its Section 1104 establishes a national healthcare operating rule mandate in support of the industry’s ongoing administrative simplification efforts. The first healthcare operating rule set, issued by CMS in July 2011, mandates the adoption of CAQH CORE Operating Rules for Eligibility and Claim Status transactions. This mandate applies to all HIPAA covered entities and is effective January 1, 2013. Subsequently, on January 1, 2014, operating rule regulations will become effective for Electronic Funds Transfer (EFT) and Electronic Remittance Advice (ERA) transactions.

What is a HIPAA covered entity? A HIPAA covered entity is any organization or corporation that directly handles Personal Health Information (PHI) or Personal Health Records (PHR). The most common examples of covered entities include hospitals, doctors’ offices and health insurance providers.

If you haven’t started yet, better get a move on. There is quite a bit of information to sift through, and you need to determine if you are compliant. The best source of information for these rules is the CAQH CORE Phase I and Phase II documents which can be found on the CAQH website http://www.caqh.org/. You don’t have to get the certification, but the documentation found on this site is extremely helpful in determining your compliancy.

The transaction sets that need to be compliant by the end of this year are the 270/271 and 276/277. Other items covered that must be compliant by the end of the year: mandated times your systems must be available for receiving and sending, “safe harbor” connectivity requirements, normalizing patient last name, “standardized” companion guides, and response times.

Let’s start with the transaction sets. The biggest changes here are to the EB (CAQH Phase I CORE 154 rule and Phase II CORE 260 rule) and AAA (CAQH Phase II CORE 259 rule) segments. Review these carefully as there are very explicit rules as to what data should be sent and when.

Next big one is the ruling on connectivity (CAQH Phase I CORE rule 153, 155, 156, 157, CAQH Phase II CORE rule 250, 270), system availability (CAQH Phase I CORE rule 157 and Phase II CORE rule 250), and companion guides (CAQH Phase I CORE rule 152). Once again there are very explicit rules on each of these subjects.

Hopefully everyone is already working on this compliancy and have it well in hand. Don’t be dismayed, it’s really not as bad as it looks!

Take the initiative and create as thorough a testing plan as you can. Remember – test, test, test, test, and test again. I can’t stress this enough.

You are now ready to start testing with your trading partner, which could include a provider, clearinghouse, another payer, etc. Do you know what needs to be tested, and what results you should expect? It isn’t enough to just say that the transaction set clears everything just fine; you need to know what results you expect.

Testing your send and receive abilities with your trading partner is crucial. For instance, you want to receive an 834 transaction (Benefit Enrollment and Maintenance) from your trading partner. One scenario would be to have them change the member’s gender and send that in the 834. Your expected results would be that when you receive the transaction and it loads into your system, that particular member’s gender will be changed in your system. Changing different information for members is a good way to test to see if the data received will load into your system without any problems.

Can your trading partner handle multiple instances of a member COB loop? Or can you? You would be surprised how many can’t. This is definitely a good one to test in an 834. The more of these types of scenarios you can identify to test the better off you will be in the long run.

A good way to start is by creating a testing matrix. The testing matrix is one way to list all the different aspects you are testing and the expected results. Engage your stakeholders in this activity as well. They will probably think of items you may not. The more items you can list to test, the less likely you will run into issues down the road. Below is a sample testing matrix for an 834 transaction. You will want to design yours based on your testing needs.

Strive to have your testing environment as closely mirrored to your production environment as possible. It never seems to fail, even though your testing and production environment may be identical, that what did work correctly in test may not in production. Plan for this to happen, because chances are it will.

Of course you can’t think of every possible testing scenario, but by creating the testing matrix you will probably hit 99% of them. The 1% are usually those scenarios that happen once in a blue moon.

As your grandmother used to say, “You can catch more flies with honey than with vinegar.” This is the attitude you should use when establishing rapport with your trading partners. It also works well when dealing with most situations.

This doesn’t mean that you have to bend over backwards and acquiesce, but if you are reasonable and have your facts together before speaking with them, it will go a long way. Most of your trading partners are just like you; they want to get the job done with the least amount of problems and want to work with you in getting issues resolved.

If you go into the situation yelling and demanding, you have already lost the battle long term. It might get your current issue resolved, but in the future they might be less likely to work with you as fast for resolutions. Having the issue well researched on your end before contacting your trading partner puts you well ahead of the game. You can talk with them intelligently regarding the perceived issue, and they have more information to help research the problem on their end.

However, sometimes you reach a point where you have to escalate the situation (i.e. the urgency of the situation not being understood). Knowing when to do this is just as important as knowing when NOT to. If you have established that good rapport they are more inclined to push your problem resolution to the top of the list.

Remember though, “poor planning on your part does not constitute an emergency on theirs.”

It is very important to make sure you determine your hardware requirements if you are implementing EDI for the first time, changing your EDI software or your EDI data needs.

If you have already met your needs then you’re ahead of the game. If not, then once again make sure you get all key stakeholders involved to make the determination as to what your expected needs now and in the near future may be. Always try to plan for the future and not just your immediate needs. One of the first things you should do is a requirements gathering. You might want to consider doing a JAD (Joint Application Design) session. Some of the questions you might need to address are:

1. Do you have all the processing power needed?
2. Will your system accommodate the new software?
3. Will your system accommodate the new data needs?
4. Do you have the communications setup needed?

These are just some of the issues that need to be addressed. Everything depends on your processing requirements and needs.

After the requirements have been compiled, have another meeting with the key stakeholders to review. This will help to clarify any ambiguities. Once everyone has agreed to the requirements you can determine what, if anything, you will need to buy. You can then put together your RFP to send out to vendors.

The time spent on the front end gathering detailed requirements helps to eliminate unnecessary delays and affects system quality.

Choosing your clearinghouse or VAN is a very important step, especially if you are in healthcare. In healthcare you need to make sure they are HIPAA compliant, which means they will be able to handle all the mandated transaction sets. Other industries have different requirements. Whichever clearinghouse you choose, you need to make sure they can handle all the transaction sets you might want to utilize.

When shopping for your clearinghouse or VAN, make a check list of your requirements. Here are a few of the most common questions you’ll want to address in creating your list:

1. What transaction sets can they handle? In healthcare, some of the transaction sets would be 834, 837, 835, 270/271, 276/277, etc.
2. What is the problem resolution process? Who do you contact? How is the issue resolved? If there is a programming change how long does it take for the change to be effective?
3. How is data transmitted? Is this done via web connection, SFTP, FTP, etc?
4. How often is data transmitted? Is data transmitted real time, batch, once daily, etc?
5. What is the cost per transaction set? Is the charge per ISA, transaction set, or bytes?
6. What is the initial set up fee?
7. What is the contract period?
8. What additional expenses are required? Do you need additional hardware, software, programming, etc. to trade data with the clearinghouse?

It is a good idea to have at least 2 different proposals put together. Best case and acceptable scenarios, with justification for each. This will give management a good idea of why you are proposing a particular clearinghouse/VAN.

Once you have gathered all the information you can put together the proposed budget for this implementation.

Whether this is an implementation of its own or part of a larger implementation, keep in mind to get all affected parties involved. This will help eliminate issues further down the road.

Are there any additional questions you would consider for your requirements list?

This is a very important step in the implementation of EDI. This step informs several of your other decisions; hardware, additional software, staffing, etc. Your previously identified data needs will also help to determine your software package.

When shopping for your EDI software package, make a check list of your requirements. Here are a few of the most common questions you’ll want to address in creating your list:

1. Is it flexible? If your data needs to be changed, how easily changes can be made to the software will be critical.
2. Will you need additional hardware? Your current hardware may not have the memory, storage, or speed required by the data needs and software package.
3. Will you need additional software and/or programming? Is the software flexible enough to integrate with your current system or is additional software required and/or do you need additional programming to integrate the data to/from your system?
4. Will additional staff be required? Do you already have staffing necessary for the programming of the software?
5. Will additional training be required? Chances are, if you are implementing a new software package then training will be required. If so, what is the cost?
6. Will it require on site personnel from the software company for installation? If yes, is this cost part of the software purchase or is it an additional cost.
7. What is the total cost of the software package? Often this is a major factor on what software package you decide to purchase.

Once you have determined which software package will work best for your company you can put together the proposed budget of total cost including software, hardware, staffing, training, etc. This will give you a good picture of what the total cost will be for implementation.

It is a good idea to have at least 2 different proposals put together: best case and acceptable scenarios, with justification for each. This will give management a good idea of why you are proposing the purchase of a particular scenario.

What other tips would you follow when shopping for an EDI solution?

In the previous blog we discussed the importance of knowing your data and business requirement needs. This is one place where that becomes important. If you already know your needs it makes it much easier to start your data mapping.

First you should contact your trading partner. They should have some type of functional specs which state what they expect to send to you or receive from you or these are specs they will request from you.

Let’s begin with the layout of the transaction set for outbound data. I have found that the best way to start is to take the segments of the transaction set and put them in an Excel spreadsheet, keeping in mind to maintain the segment looping structures. Once you have the segments in your document you can then flesh them out further by putting in the individual data elements and sub-elements for that segment. As you are doing this it would be a good idea to mark each data element as to whether or not they are required, optional or situational. This will help you determine what needs to be present when creating the final product.

Now that you have the transaction set laid out in an editable format you can start marking those fields that fit the identified business needs. You can now use this document to cross reference to your trading partners’ specs as well. Keep in mind that if the data element states it is a required field you must have it populated with data.

Once this layout is complete it is time to start cross mapping to your database. Chances are you will be mapping to numerous tables based on the database layouts where each business unit utilizes their particular data, etc. These should all be reflected in your document and you should be working with your database administrator to make sure everything is being placed into or pulled from the proper table and field as well as whether or not any additional fields will need to be added to the database tables.

Now that you have your document complete you should review once again with the vested parties to make sure everything is as expected. This is a good time to identify any additional requirements or changes that need to be made before you start the actual mapping process.

You are now ready to start working with the mappers to create the transaction set.

Hopefully everyone answered ‘yes’ and you had a smooth transition. In this blog we will discuss some of the items we need to keep in mind when either transitioning or implementing EDI.

Whether you are getting ready to transition to a new standard or initiating EDI for the first time, remember the most important thing is to KNOW YOUR DATA NEEDS!

Knowing what data you expect to send and receive is one of the most important items you can establish.

First, review the standard for the transaction set(s) you want to use (some of the transaction sets used for healthcare are 835, 834 837, 270/271, etc). Whether this is for Healthcare, Automotive, or any other standard, this is very important. This will give you an idea of what data is available and what you can plan to accommodate. Remember, just because it is in the standard does not mean you need that piece of data.

Once you have reviewed the standards, you need to get everyone involved: business users, a data mapper, a database administrator, trading partners and anyone else who might have a vested interest. It might surprise you as to what data they will actually need and utilize. Whether the data is used in the data warehouse or for reports it is important to identify your business needs. Also, try to plan for future business requirements. Just because you don’t use that piece of data right now doesn’t mean you might not need it as standards evolve. You can start with a “wish list” and pare it down from there. Keep in mind that just because you want to receive a particular piece of data, your translation software may not currently be set up to capture, your trading partner may not be able to accommodate, or your clearinghouse may not have that set up in their maps. We all would like to have everything, but it is not always practical.

If you are converting to a new standard this is the chance to change things. Just because it has always been done that way is no reason to continue – that may not be the best practice. This gives you a chance to make things better and perhaps correct things that were not working right before. If you are initiating a new transaction set, this is the perfect opportunity to grab the data you need and get everything set up right the first time. This is where it is important to get the users involved. As the person doing the research you may not think a piece of data is important, but to them it may be very necessary.

When you have identified all your data needs you are ready to move on to the next step – mapping the fields in the standards to your database. We will talk about that in our next blog.

Have you initiated EDI? What data issues did you face? How did you overcome them?