healthcare EDI softwareWhat to look for in a healthcare data solution
What is Healthcare EDI Software?
Healtcare EDI Software enables the communication of information that has traditionally been sent in paper form. When working with HIPAA data this process requires a specialized Healthcare EDI database solution to promote an X12 structured and HIPAA compliant way to secure and track patient data. This data is typically transmitted between healthcare providers, plans, payers, clearinghouses, third party administrators (TPAs), and other healthcare software companies known as intermediaries. EDI healthcare transactions are based on the standardized formatting rules of a governing body X12.org conforms to HIPAA mandated national standards.
How is EDI different for healthcare?
Large EDI files - Transactions such as claims (837I, 837P) and monthly enrollment snapshots tend to be much larger than typical supply chain EDI transactions. That’s why it’s important to look for software that’s built for EDI healthcare. If your legacy system performance suffers when pocessing large claim for enrollment files, try utilizing one of our EDI validation tools to locate SNIP Level errors, edit files, divide processing into more manageable chunks. Try to avoid solutions made for other industries that parse EDI into XML or similar bloated in-memory structure. This will increase the payload of the ANSI EDI file many times over and cause slow system performance.
5 ways to determine if a vendor is truly focused on healthcare EDI software:
- NPI -According to HIPAA, all healthcare clearinghouses and health plans should use the National Provider Identification Standard (NPI) to identify covered providers. It’s a unique identification for providers. The 10-digit number is a surrogate key that has no meaning outside of an assigned number.
- WEDI SNIP Level Edits - A major difference for EDI healthcare transactions is a system capable of industry WEDI SNIP Level Edits. At the minimum, your EDI software should provide SNIP levels 1 and 2.
- PHI data security - HIPAA mandated security measures to protect patient identifying data elements. Your system should provide the necessary functions to secure and protect patient information.
- 999, not 997 - It’s always interesting to see a company offering healthcare software solutions for EDI and see them mention 997 Acknowledgements (ACK). All HIPAA compliant systems should be providing 999 as mandated by the 5010 standard.
- 5010, not 4010 - Again, when you talk to vendors and they mention 4010, it’s an indication they focus on supply chain and other non-healthcare EDI solutions. In order to be HIPAA compliant, healthcare organizations should be using 5010 standards.
What transaction sets are specific to healthcare?
5 common healthcare transaction sets:
- 837I – Institutional Claim billed from hospitals and other in-patient and out-patient providers. It takes the form of UB04 and 837I.
- 837P – Professional Claim billed by physicians, medical offices, suppliers, and other non-institutional providers. It takes on the form of a CMS1500 and 837P.
- 837D – Dental claim billings are sent as 837D files by dental providers.
- 834 – Member Enrollment file providing memeber file maintenance and enrollment information for plans. It includes new, change, delete, and reinstatement information.
- 835 - Healthcare payments.
Many higher volume healthcare organization rely on their EDI Gateway solution to manage all HIPAA transactions, trading partners, and EDI workflows.
What is HIPAA and how does it apply to EDI?
HIPAA stands for Health Insurance Portability Accountability Act and was put into legislation to protect patient’s medical information. It outlines provisions and security measures to handle healthcare data. The HIPAA security provisions outline how Protected Health Information (PHI) should be safeguarded. Your system should be built to help your organization protect a patient’s past and current medical data, making sure it is secure and protected. Any patient data that can reasonably identify the person should be secured. Examples of PHI data elements include name, birth date, address, and social security number.
5 common system challenges with processing healthcare data:
- Large EDI files – Large 834, 837 files can be difficult scale without a proven EDI system.
- Protecting PHI data – According to HIPAA compliance, an healthcare focused platform should provide protection and security of patient information. Complex standardized rules – WEDI SNIP level edits should come out-of-the-box with such solutions.
- Complex custom rules – Plans, TPA’s, and other healthcare EDI software companies should provide a framework to implement customized rules for rulesets such as member matching, custom enrichments, and other custom business rules.
- Member matching – Matching a member requires complex logic. Implementing a “fuzzy match” for existing members can be challenging for EDI solutions.
- Non standards - Source and destination system formats that are non-standardized can be difficult to transform.
Healthcare data specificity checklist
When choosing an EDI Software or managed service, ask your vendor the following questions.
- Can you show WEDI SNIP Rule support (SNIP 1, 2 minimum)?
- How are elevated SNIP edits implemented, such as SNIP 3?
- How long will it take to install the EDI software; how invasive?
- Will the system scale and how does it handle extremely large 834 and 837 files?
- How is PHI data handled in the EDI platform?
- Are there alternatives such as Product Software, Hosted, SaaS, and Managed Services offerings?
- Was this Healthcare EDI software originally developed for HIPAA transactions?
- How much will professional services cost?
- Does it take more than 3 days to onboard a trading partner?
Come leverage the proven power of a healthcare focused EDI software solution. Contact us to schedule a live T-Connect product demo.