|
Business Case for DP Solutions’ Healthcare EDI Tools
If you are in a position where you need to process Healthcare EDI
files such as the professional healthcare claim (837P), the institutional healthcare
claim file (837I), or the healthcare payment and remittance advice file (835) you
should be doing research in order to determine whether you will “build” versus “buy”
your solution.
Before you begin building a solution, it may be helpful to consider
the following facts that are specific to just one healthcare EDI transaction, the
healthcare professional claim (837P).
- The 837P EDI file is complex and hierarchical in nature. In order to be
able to utilize the data it contains you have to be completely familiar
with its structure. For example the professional healthcare claim (837P)
can contain up to 222 segments, and 879 elements. The 837P implementation
guide published by Washington Publishing is 742 pages in length. This is
the guide that fully describes and explains the structure of the healthcare
professional claim file. You will need to read this entire document more
than once in order to understand the EDI file structure and various business
scenarios.
- You will need to validate all incoming and outgoing 837P files to make sure
they are correct in structure and content. There are seven levels of testing
and compliance that are defined within the WEDI SNIP white paper on Testing and
Certification. The DPS EDI tools perform validation of EDI files through the
use of a SEF file which is similar to a schema file. Different SEF files can
be constructed for various trading partners so that specific trading partner
rules can be defined. If you build your own solution, you will need to learn
about SEF file structure and the rules for 837P EDI file validation.
- You will need to correctly parse the information contained in the 837P file and
store this information within some sort of relational database structure.
This database structure will at least need to provide for containers for the
222 segments, and 879 data elements that are part of an 837P, not to mention
fields for defining relationships between the tables.
- You will need to correctly construct an 837P file that may vary in structure
and content based on your underlying business requirements.
- The DPS 837P MS-SQL database consists of 106 data tables, 233 stored procedures
and 1 view. It can contain every piece of data ever contained in any 837P EDI
file.
- The DPS 837P EDI parser contains 11861 lines of tested, proven code. It
performs file validation and then parses the file data and inserts it
into the 837P database.
- The DPS 837P EDI serializer contains 7687 lines of tested, proven code.
It constructs an 837P file based on specific trading partner rules and
then validates the file.
- The DPS EDI tools have been developed by a team of professionals over a period
of years and through various iterations.
- The DPS EDI tools are installed and running in numerous satisfied accounts.
- DPS can install the EDI tools onto your server and be processing EDI files through
the components in less than an hour.
How long will it take you to learn the subject matter, design
your database, build and test your tools for just one EDI transaction?
The DP Solutions EDI components are already built, tested and functional.
The DP Solutions EDI tools are distributed with source code so you have total freedom and
independence to customize the solution to fit your business needs.
For more information:
Back To Top
|
