2. EDI service landscape
834 – Insurance eligibility and benefit verification Paper based claims submission – UC05, CMS1500
837 - Claims information 835 – Remittance advice
999 - Acknowledgment
Generation and verification
of EDI 837P and EDI 837I
file from flat file
Parsing EDI 835 file and
converting it to simple
readable flat file
Conversion from flat file to
EDI format
To map data from flat
file to EDI format
Report generation
3. Nitor’s capabilities in EDI transition
iOS App
• Generating EDI 837P and EDI 837I file from flat file received from various providers to be
submitted to payer
• Parsing EDI 835 file received from payer and converting it to simple readable flat file and
entering the same in database so that reports could be generated easily
• Generating EDI 834 file and sending the same to the payer for benefit and eligibility
verification
• Support conversion of messages between many different formats, such as, X12, EDIFACT, XML,
Proprietary formats (SAP IDOCs, JDE formats, etc) and also map directly to Databases
• Convert flat file data into EDI format
• Parse the EDI file received in desired format like flat file, .doc etc
• Map data from flat file to EDI format
4. Data handshake during development:
Masking for Compliant Engagement
• Masking PHI data to maintain confidentiality
• Maintaining Audit compliance – To maintain user wise for data accessed,
data shared, login time, logout time etc)
We need data
for testing
/execution
Because of
HIPAA, you
can not
provide us
with REAL
data
Data can
not cross US
boundary
Nitor
Provides
you
“MASKER”
You MASK
data at your
place
You make
the data –
“non-
decipherable
”
Nitor gets
Data for
testing that
can not be
IDENTIFIED
Compliant
Engagement
• Secure interoperability while sharing sensitive data
• Copy sensitive data outside your production environments
• Move your development to the cloud or offshore
• Need regulatory or audit compliance (i.e.- HIPAA, Dodd-Frank)
• Interoperability among ACO & HIE participants