Question 1

What is X12 EDI?

Accepted Answer

X12 EDI is a data format based on ASC X12 standards developed by the American National Standards Institute (ANSI) Accredited Standards Committee (ASC). It is used to electronically exchange business documents in specified formats between two or more trading partners. X12 EDI releases are known by a version number. Learn more about PilotFish’s Interface Engine with exclusive X12 EDI tools to process all your transactions.

Question 2

What is the X12 format?

Accepted Answer

X12 is a standard for Electronic Data Interchange (EDI) developed and maintained by the American National Standards Institute (ANSI) Accredited Standards Committee (ASC). The X12 standard governs the exchange of business documents (e.g., purchase orders, invoices, healthcare claims, etc.) in standard electronic formats between trading partners – for example, EDI 837 Health Care Claim Transaction Set. PilotFish provides broad support for all X12 standards and HIPAA transactions.

Question 3

What is EDI?

Accepted Answer

Electronic data interchange (EDI) is the structured exchange of business documents between organizations by electronic means based on widely accepted and agreed to standards. EDI standards govern electronic data exchange in finance, government, healthcare, insurance, retail, transportation and more.

Question 4

What does EDI stand for?

Accepted Answer

EDI is an abbreviation and shorthand for Electronic Data Interchange, a structured way to transmit data between computer systems using established message formats and standards. The businesses or organizations exchanging data are called trading partners in EDI terminology.

Question 5

What is an EDI transaction?

Accepted Answer

An EDI transaction set or EDI transaction is a group of one or more data segments representing a business document exchanged between trading partners to carry out financial or administrative activities – e.g., EDI 820 Payment/Remittance, EDI 999 Acknowledgment, EDI 834 Benefit Enrollment/Maintenance. The standard prescribes the formats, character sets and data elements used. View the format &amp; description of the most common X12 EDI transactions.

Question 6

What is EDI capable?

Accepted Answer

EDI capable is the ability to send and receive electronic business documents in a specific format based on established standards. It also refers to having in place an EDI solution that can streamline business workflows and onboard partners quickly. EDI capable can further encompass strategy and solutions that deliver efficiencies and high productivity. Learn more about PilotFish’s EDI Capable Integration Engine with built-in X12 EDI tools.

Question 7

What is EDI parsing?

Accepted Answer

EDI parsing is the process of matching the incoming data with a defined schema to identify, flag and/or fix data transformation issues. EDI parsing errors include data type mismatches, invalid records, incorrect values, incorrect segment and element usages, etc. While X12 EDI formats are based on the published standards – in the real world, deviations and differences between X12 EDI transactions are the norm. Learn more about PilotFish’s built-in EDI parser.

Question 8

What is EDI mapping?

Accepted Answer

EDI mapping is the process through which EDI data is translated and transformed into a format more easily used or required by a trading partner or both. Data mapping is the capability to map source data fields to related target data fields in converting EDI to other formats such as XML, Excel, databases, JSON or other EDI formats. Learn more about EDI mapping with PilotFish.

Question 9

Which is better EDI or API?

Accepted Answer

EDI (Electronic Data Interchange) is used for the transfer of structured data, by agreed message standards, from one computer system to another without human intervention. EDI is one of the safest ways to transfer data. Companies can exchange large amounts of EDI data simultaneously as well as transfer huge volumes via a single transfer. An API (Application Programming Interface) is a connection between computers or between computer programs via calls, working on a request-response basis.

Question 10

Is API better than EDI?

Accepted Answer

Application Programming Interfaces (APIs) work on a request-response basis. They are not intended for transactional interfaces or standards-based integration. While very beneficial in many integration scenarios, creating APIs and integrating with them also requires programming expertise. For most backend internal system integrations, APIs are more costly to develop and maintain. Increasingly, trading partners are using a mix of APIs and EDI.

Question 11

What is healthcare EDI?

Accepted Answer

Most commonly, healthcare EDI refers to the HIPAA (Health Insurance Portability and Accountability Act) rules requirement that any health plan, healthcare clearinghouse and healthcare provider transmit claims and other patient-identifiable health information in specific X12 EDI healthcare transaction sets. HIPAA EDI transactions include claims, encounters, eligibility, claim status inquiries, remittance advice and benefit enrollment.

Question 12

What is HIPAA EDI?

Accepted Answer

In the electronic exchange of financial and administrative healthcare transactions, the Health Insurance Portability and Accountability Act (HIPAA) requires all health plans, healthcare clearinghouses and healthcare providers to use HIPAA X12 EDI transaction sets for claims submission, enrollment/disenrollment, eligibility, payment to provider, claims status, certification/ authorization and premium payment to health insurance plan.

Question 13

What are healthcare EDI transactions?

Accepted Answer

In EDI, a single business document is called a “transaction set” or “message.” HIPAA requires all health plans, healthcare clearinghouses and healthcare providers to use HIPAA X12 EDI transaction sets for structured message exchange. Electronic transactions covered include healthcare claims, claims status and remittance advice, eligibility verifications and responses, referrals and authorizations, and coordination of benefits.

Question 14

How does EDI work in healthcare?

Accepted Answer

Healthcare EDI refers to the HIPAA (Health Insurance Portability and Accountability Act) requirement that any health plan, healthcare clearinghouse and healthcare provider transmit claims and other patient-identifiable health information in specific X12 EDI healthcare transaction sets. HIPAA EDI transactions include claims, encounters, eligibility, claim status, remittance advice and benefit enrollment.

Question 15

What is an EDI claim?

Accepted Answer

HIPAA X12 EDI transaction sets are structured messages standardized and required for claims submission, enrollment/disenrollment, eligibility, payment to provider, claims status, certification/authorization and premium payment to health insurance plans by all health plans, healthcare clearinghouses and healthcare providers.

Question 16

How does EDI work in medical billing?

Accepted Answer

EDI allows entities within the healthcare ecosystem to exchange medical, billing and other information quickly and cost effectively. Medical billing involves timely exchange of specific HIPAA EDI documents (claims, remittance advice, eligibility inquiry, claim status inquiry), accurate medical coding, and secure information exchange to and from provider and payer entities as well as third-party vendors and clearinghouses.

Question 17

What are some benefits of using EDI for healthcare data exchange?

Accepted Answer

EDI can help reduce costs, improve accuracy and efficiency, enhance patient privacy and security, and improve overall healthcare quality and outcomes.

Question 18

What are some emerging trends in EDI healthcare?

Accepted Answer

Cloud-based EDI solutions, blockchain technology, and AI driven analytics are some emerging trends in EDI healthcare parsing and validation.

Question 19

What is EDI healthcare data conversion, and how does it work?

Accepted Answer

EDI healthcare data conversion is the process of converting healthcare data into EDI format to enable secure transmission and integration into other systems. It involves mapping data elements from the source format to EDI standards, such as X12.

Question 20

What are the benefits of using EDI in healthcare data integration?

Accepted Answer

EDI enables secure and real-time exchange of healthcare data between providers, payers, and patients. It helps reduce errors, streamline workflows, and improve data accuracy and patient care.

Question 21

What is EDI 834 data conversion, and why is it important for technical users interested in PilotFish’s integration tools?

Accepted Answer

Electronic Data Interchange (EDI) 834 data conversion is the process of translating data between different formats, often involving transforming data from CSV, XLS/Excel, or TXT to the EDI 834 format used for Benefit Enrollment and Maintenance. For technical users considering PilotFish’s integration tools, this process is vital as it enables seamless data communication between systems, facilitating efficient data integration and management. Watch our EDI 834 Transformation Video.

Question 22

What is the role of EDI in healthcare supply chain management?

Accepted Answer

EDI enables healthcare organizations to automate supply chain management processes, such as inventory tracking, order processing, and invoicing. It helps reduce manual errors, improve efficiency, and increase supply chain visibility.

Question 23

What are the key considerations for selecting an EDI software provider for healthcare data conversion and integration?

Accepted Answer

Key considerations include expertise in healthcare EDI, knowledge of industry regulations, reliability and scalability of the platform and support and training services.

Question 24

How can healthcare organizations integrate EDI with their existing EHR and practice management systems?

Accepted Answer

Healthcare organizations can integrate EDI by using middleware solutions that enable seamless data exchange between different systems, or by using APIs that enable real-time data transfer between systems. See EHR Integration Solutions.

Question 25

What are the key benefits of using EDI for healthcare data conversion and integration?

Accepted Answer

Key benefits include improved data accuracy and timeliness, reduced costs and errors, increased efficiency and productivity, enhanced patient care and outcomes, and compliance with industry regulations and standards.

Question 26

What are some common EDI healthcare transactions?

Accepted Answer

Claim submissions (EDI 837), remittance advice (EDI 835), eligibility verification (EDI 270/271), and prior authorization (EDI 278) are some common EDI healthcare transactions.

Question 27

What are the HIPAA X12 transaction sets?

Accepted Answer

The key X12 EDI transaction sets specified by HIPAA include:

EDI 270 Healthcare Eligibility/Benefit Inquiry
EDI 271 Healthcare Eligibility/Benefit Response
EDI 275 Patient Information
EDI 276 Healthcare Claim Status Request
EDI 277 Healthcare Claim Status Notification
EDI 277 Healthcare Claim Acknowledgment
EDI 278 Healthcare Service Review Information
EDI 820 Payroll Deducted and other group Premium Payment for Insurance Products
EDI 824 Application Advice
EDI 834 Benefit Enrollment and Maintenance
EDI 835 Healthcare Claim Payment/Advice
EDI 837 Healthcare Claim and Maintenance
EDI 997 Functional Acknowledgment for Healthcare Insurance
EDI 999 Functional Acknowledgement
EDI TA1 Interchange Acknowledgment

Question 28

What X12 EDI supply chain transactions are used in healthcare?

Accepted Answer

Common Types of X12 EDI Supply Chain Transactions include:

EDI 180 Return Notification and Authorization
EDI 810 Invoice
EDI 820 Payment Order and Remittance Advice
EDI 824 Application Advice
EDI 832 Price/Sales Catalog
EDI 846 Inventory Inquiry and Advice
EDI 850 Purchase Order
EDI 855 Purchase Order Acknowledgment
EDI 860 Purchase Order Change
EDI 864 Text Message
EDI 997 Functional Acknowledgment
EDI TA1 Interchange Acknowledgment

Question 29

Does PilotFish support all X12 EDI 5010 healthcare transaction sets including 270/271, 275, 276/277, 277CA, 277P, 278, 820, 824, 834, 835, 837 I/P/D, 999?

Accepted Answer

Yes, PilotFish fully supports all the X12 EDI 5010 transaction sets.

Question 30

Where does the EDI 835 and EDI 837 data typically come from?

Accepted Answer

The EDI 835 and 837 data, essential in healthcare EDI (Electronic Data Interchange), usually originates from healthcare clearinghouses or practice management systems. The EDI 835 transaction covers healthcare claim payments, while the EDI 837 transaction involves claim submission. The data extraction process can vary based on the source system. For more details, see our EDI 837 demo video or read this HIE &amp; Claims Clearinghouse case study.

Question 31

What is EDI 270 Eligibility, Coverage of Benefit Inquiry?

Accepted Answer

The EDI 270 transaction set and format is used to inquire about the eligibility, coverages or benefits associated with a benefit plan, employer, plan sponsor, subscriber or dependent under the subscriber’s policy. The transaction set may be used by all lines of insurance such as Health, Life, and Property and Casualty. For more detailed information see EDI 270 format and example.

Question 32

What is EDI 271 Eligibility, Coverage of Benefit Information?

Accepted Answer

The EDI 270 transaction set and format is used to communicate information about or changes to eligibility, coverage or benefits from information sources (such as – insurers, sponsors, payors) to information receivers (such as – physicians, hospitals, repair facilities, third party administrators, governmental agencies). This information includes but is not limited to: benefit status, explanation of benefits, coverages, dependent coverage level, effective dates, co-insurance, co-pays, deductibles, exclusions and limitations. For more detailed information, see EDI 271 format and example or read this EDI 271 integration case study.

Question 33

What is EDI 275 Patient Information?

Accepted Answer

The EDI 275 transaction set is used to communicate individual patient information requests and patient information between separate health care entities in a variety of settings to be consistent with confidentiality and use requirements. Patient information consists of demographic, clinical, and other supporting data. The EDI 275 can be sent either solicited or unsolicited. The EDI 275 Patient Information is an EDI transaction designed to carry attachments. For more detailed information, see EDI 275 format and example.

Question 34

What is EDI 276 Healthcare Claim Status Request?

Accepted Answer

The EDI 276 transaction set is used by a provider, recipient of healthcare products or services, or their authorized agent to request the status of a healthcare claim or encounter from a healthcare payer. Note: EDI 276 does not replace the EDI 837 Healthcare Claim transaction set, but is intended for use after the receipt of a claim or encounter information. Such a request may occur at the summary or service line detail level. For more detailed information, see EDI 276 format and example.

Question 35

What is EDI 277 Healthcare Claim Status Notification?

Accepted Answer

The EDI 277 is used by a healthcare payer or authorized agent to notify a provider, recipient, or authorized agent regarding the status of a healthcare claim or encounter or to request additional information from the provider regarding a healthcare claim or encounter, healthcare services review, or transactions related to the provisions of healthcare. The notification may be solicited or unsolicited. EDI 277 does not replace the Healthcare Claim Payment/Advice Transaction Set (EDI 835). It is not used for account payment posting. The notification may be at a summary or service line detail level. For more detailed information, see EDI 277 format and example.

Question 36

What is EDI 277 Healthcare Claim Status Response?

Accepted Answer

The EDI 277 is Acknowledgement/Returned as Unprocessable Claim-The claim/encounter has been rejected and has not been entered into the adjudication system. The EDI 277 transaction set has been specified by HIPAA for the submission of claim status information to respond to a previously received EDI 276 Claim Status Inquiry, to request that a payer provide additional information about a submitted claim (no 276 involved), or for a payer to provide claim status information to a provider via the EDI 277, without having received a 276.

Question 37

What is EDI 277CA Healthcare Claim Acknowledgment?

Accepted Answer

The EDI 277CA Healthcare Claim Acknowledgment provides a claim level acknowledgment of all claims received in the payer’s pre-processing system before submitting claims into an adjudication system. It is created in receipt of an incoming EDI 837 5010 claim submission transaction. The 277CA offers a common report interface to payers and providers. Most clearinghouses and payers now use the 277CA as their standardized reporting mechanism for 5010. The 277CA reports on whether pre-adjudication validation found the claims acceptable for adjudication. There are no Category Codes signifying ‘accepted with warning’. The 277CA cannot report syntax issues. The EDI 277CA transaction is not required by HIPAA. For more information, refer to the TR3 Implementation Guide (Technical Report Type 3).

Question 38

What is EDI 278 Healthcare Services Review Request?

Accepted Answer

The EDI 278 transaction set can be used to transmit healthcare service information, such as subscriber, patient, demographic, diagnosis or treatment data for the purpose of request for review, certification, notification or reporting the outcome of a healthcare services review. Expected users of this transaction set are payors, plan sponsors, providers, utilization management and other entities involved in healthcare services review. A single 278 is commonly used for one patient and one patient event. For more detailed information, see EDI 278 format and example.

Question 39

What is EDI 278 Healthcare Services Review Response to a Request?

Accepted Answer

The EDI 278 transaction set can be used to responses to requests for healthcare service information, such as subscriber, patient, demographic, diagnosis or treatment data for the purpose of request for review, certification, notification or reporting the outcome of a healthcare services review. A single 278 is commonly used for one patient and one patient event. For more detailed information, see EDI 278 format and example.

Question 40

What is EDI 820 Payment Order/Remittance Advice?

Accepted Answer

The EDI 820 transaction set can be used to make a payment, send remittance advice, or make a payment and send remittance advice. This transaction set can be an order to a financial institution to make a payment to a payee. It can also be a remittance advice identifying the detail needed to perform cash application to the payee’s accounts receivable system. The remittance advice can go directly from payer to payee, through a financial institution, or through a third-party agent. For more detailed information, see EDI 820 format and example or read this EDI 820 integration case study.

Question 41

What is EDI 824 Application Advice?

Accepted Answer

The EDI 824 acknowledgment is used as a means of communicating errors in a previous transaction. The EDI 824 report allows the trading partner who sent the original transaction to identify, correct and resubmit that transaction. In healthcare applications, the optional EDI 824 transaction meets HIPAA 5010 requirements for non-claims (EDI 276, 270 and 278) transactions. In practice, EDI 824 is used or even required as an acknowledgment to EDI 837 Claims as well. The 824 acknowledgment also is used report the success of failure of an EDI 275 attachment transaction. The 824 can embed an HL7 report on the acceptance of the HL7 or identifying specific HL7 syntax errors. For more detailed information, see EDI 824 format and example.

Question 42

What is EDI 834 Benefit Enrollment and Maintenance?

Accepted Answer

The EDI 834 transaction set can be used to establish communication between the sponsor of the insurance product and the payer. The sponsor is the party or entity that ultimately pays for the coverage, benefit or product. A sponsor can be an employer, union, government agency, association, or insurance agency. The payer refers to an entity that pays claims, administers the insurance product or benefit, or both. A payer can be an insurance company, health maintenance organization (HMO), preferred provider organization (PPO), government agency (Medicare, Medicaid, etc.), or an entity that may be contracted by one of these former groups. For more detailed information, see EDI 834 format and example or read the EDI 834 integration case study.

Question 43

What is EDI 835 Healthcare Claim Payment & Remittance Advice?

Accepted Answer

The EDI 835 Healthcare Claim Payment and Remittance Advice transaction set is used by insurance plans to make payments to healthcare providers and/or provide Explanations of Benefits (EOBs) remittance advice. When an EDI 837 Healthcare Claim is submitted by a healthcare service provider, the healthcare insurance plan uses the EDI 835 to detail the payment to that claim. What charges were paid, denied, or adjusted; the presence of a deductible, co-insurance, co-pay, etc.; bundling or splitting of claims or line items; how payment was made (e.g. clearinghouse). Healthcare providers use the 835 to track what payments were received for the services they provided and billed. For more detailed information, see EDI 835 format and example or read this EDI 835/837 revenue recovery case study.

Question 44

What is EDI 837 Healthcare Claim: Professional?

Accepted Answer

The EDI 837 or 837P transaction set is used for electronic claims from providers and health plans for services performed by physicians, suppliers, and other non-institutional providers for both outpatient and inpatient services. This transaction set is sent by the providers to payers, which include insurance companies, health maintenance organizations (HMOs), preferred provider organizations (PPOs), or government agencies such as Medicare, Medicaid, etc. These transactions may be sent either directly or indirectly via clearinghouses. For more detailed information, see EDI 837 format and example or read this EDI 837 integration case study.

Question 45

What is EDI 837 Healthcare Claim: Dental?

Accepted Answer

The EDI 837 or EDI 837D transaction set is used for electronic claims from providers and health plans that use EDI for dental procedures. EDI 837D can be used to submit dental claim billing information, encounter information, or both. Submitters can be providers of approved categories of dental care to payers, either directly or via intermediary billers and claims clearinghouses. For more detailed information, see EDI 837 format and example.

Question 46

What is EDI 837 Healthcare Claim: Institutional?

Accepted Answer

The EDI 837 or EDI 837I transaction set is used to transmit institutional claims submitted by hospitals and skilled nursing facilities. EDI 837I can be used to submit healthcare claim billing information, encounter information, or both. Submitters can be providers of healthcare services to payers, either directly or via intermediary billers and claims clearinghouses. For more detailed information, see EDI 837 format and example.

Question 47

What is EDI 997 Functional Acknowledgment?

Accepted Answer

The EDI 997 Functional Acknowledgment describes the syntax-level acknowledgment of the receipt of an X12 functional group. It confirms to a sender that a receiver has received the EDI transactions successfully. In addition, the acknowledgment contains an acceptance or rejection notification. HIPAA EDI Version 5010 of the standards established EDI 999 as the healthcare standard acknowledgment document, designed to replace Version 4010 997 Functional Acknowledgment. You may encounter both the 997 and 999 in use. For more detailed information, see EDI 997 format and example.

Question 48

What is EDI 999 Implementation Acknowledgment?

Accepted Answer

The EDI 999 transaction set is used to define the control structures for a set of acknowledgments to indicate the results of the syntactical and relational analysis of the electronically encoded documents, based upon a full or implemented subset of X12 transaction sets. EDI 999 does not encompass the semantic meaning of the information encoded in the transaction sets. For more detailed information, see EDI 999 format and example.

Question 49

What is EDI TA1 Interchange Acknowledgment?

Accepted Answer

The EDI TA1 Interchange Acknowledgment is used to verify the syntactical accuracy of the envelope of the X12 interchange. The TA1 will indicate that the file was successfully received, as well as indicate what errors existed within the envelope segments of the received X12 file. The TA1 verifies the envelope only. For more detailed information, see EDI TA1 format and example.

Question 50

How can healthcare providers ensure data integrity during EDI data conversion?

Accepted Answer

Healthcare providers should implement robust data validation, verification, and reconciliation procedures to ensure data integrity during EDI data conversion. They should regularly monitor their EDI systems for errors or discrepancies. See eiDashboard for Real-Time Transaction Monitoring.

Question 51

What are some common challenges in EDI healthcare data conversion and integration?

Accepted Answer

Some common challenges include data mapping errors, EDI compliance issues, data validation and reconciliation, and interoperability issues between different systems. See HIPAA Validation &amp; Compliance.

Question 52

What are some best practices for implementing EDI healthcare data conversion and integration?

Accepted Answer

Best practices include selecting the right EDI software, choosing an experienced EDI software company, conducting thorough testing and validation, implementing robust security measures, and regularly monitoring and maintaining the EDI system.

Question 53

How does EDI healthcare data conversion help with HIPAA compliance?

Accepted Answer

EDI healthcare data conversion can help healthcare organizations comply with HIPAA regulations by enabling secure and compliant transmission of electronic healthcare transactions with the right middleware. See SNIP Validation.

Question 54

How can healthcare organizations ensure EDI compliance with different trading partners?

Accepted Answer

Healthcare organizations should have a clear understanding of their trading partners’ EDI requirements and ensure their EDI software and processes are compatible. They should also monitor and maintain compliance with EDI standards and regulations.

Question 55

What is HIPAA SNIP validation?

Accepted Answer

HIPAA SNIP validation is applied to X12 EDI documents to ensure the EDI data is HIPAA-compliant. Each succeeding WEDI-SNIP Type 1-7 increases the strictness of data constraints. Support of the higher SNIP levels (SNIP Types 4-7) in an EDI solution helps to ensure robust validation and HIPAA EDI compliance checks.

Question 56

How are EDI X12 files validated?

Accepted Answer

Several parts of an EDI message can have problems that corrupt or invalidate the message contents. The EDI specification includes SNIP Types 1-7 (SNIP Levels) that define checks to make sure a given EDI message is EDI compliant and passes specific criteria for being well-formed. PilotFish provides SNIP validation out-of-the-box for Types 1-3 and Types 4-7 as an add-on. An additional EDI SNIP Validation Processor provides a preliminary overall sanity check.

Question 57

Does PilotFish offer a comprehensive rules engine for HIPAA-compliant EDI file validation and error reporting?

Accepted Answer

Absolutely. PilotFish expertly conducts SNIP validations, ensuring both integrity and compliance. For example, EDI 835 files that are generated from EDI 837 files. This meticulous validation process not only identifies errors but also presents the findings in a user-friendly XML format. Additionally, users have the flexibility to either generate detailed reports or opt for exceptions based on these validation outcomes.

Question 58

Does PilotFish provide comprehensive SNIP Levels 1 to 3 validation?

Accepted Answer

Yes, PilotFish’s base products include a thorough validation that spans the entire spectrum of SNIP standards, ensuring a detailed and complete verification process, far beyond mere surface-level checks. SNIP 1-3 is included automatically and SNIP 4-7 are optional add-ons.

Question 59

What are the costs associated with external code set maintenance?

Accepted Answer

PilotFish’s external code set maintenance service, which is vital for the current maintenance of EDI transaction codes is available for yearly updates. Fill out our Contact Us form to connect with a sales representative for pricing.

Question 60

How often are the HIPAA code sets updated with the maintenance service?

Accepted Answer

PilotFish has an automated process so that code sets are updated regularly in accordance with official releases and regulatory updates. This ensures your organization always operates with the most current information. To learn more, visit our External Code Set Maintenance page.

Question 61

What is the pricing structure for PilotFish’s External HIPAA Code Set Maintenance Service?

Accepted Answer

PilotFish’s External Code Set Maintenance Program is only available to PilotFish customers who utilize our eiPlatform and eiConsole for X12 EDI solutions. Contact Us to have a customer service representative who will assist you with detailed pricing information.

Question 62

Does PilotFish offer HIPAA Compliance Validation services?

Accepted Answer

Yes, PilotFish provides SNIP Levels 1-3 validation built into its core products (eiConsole/eiPlatform) with optional enhanced support for SNIP Levels 4-7 in its eiSuite offering. There is also an optional external EDI code set maintenance program, as well.

Question 63

Does PilotFish support LOINC code validation?

Accepted Answer

Yes, PilotFish supports LOINC codes – a subset of HCPCS codes – from the AMA and updates them quarterly.

Question 64

Will PilotFish support future industry transaction standards like ASC X12?

Accepted Answer

As an X12 Preferred Partner, PilotFish supports HIPAA 5010 standards and participates in their working group. PilotFish is already working on support for the HIPAA 8020 standard.

Structured Data

X12 EDI FAQ

X12 EDI Frequently Asked Questions

Free 90-Day Trial