E-documents are actually ASCII data strings that are sent electronically from the sending system to the receiving system and back to the sending system. The structure of the data strings different for the e-doc types. The documents are readable. However, you must understand the individual codes so that you can understand the information that the document is communicating. For instance, HIPAA e-docs start with an ISA header that includes important structural information, while HL7 e-docs begin with a MSH header. However, both contain PID segments that contains patient identification information.

Currently, the following e-document types are supported in Document Schema Designer:

EDI stands for Electronic Data Interchange. It is the direct computer-to-computer exchange of structured data, sent in a form that allows automatic processing without human intervention.

EDI, uses standard formats to pass data between different business systems. Third parties provide EDI services that enable organizations with different equipment to connect. Although interactive access may be a part of it, EDI implies direct computer-to-computer transactions into vendors' databases and ordering systems. The EDI standard is ANSI X12, developed by the Data Interchange Standards Association (DISA). ANSI X12 is either closely coordinated with or is being merged with an international standard, EDIFACT.

Beginning in the 1960s, large corporations created private networks with business partners to share information about sales, supplies, funds transfers, and order processes. Using EDI, a retailer tells a warehouse about an order, and the warehouse could immediately notify suppliers of an inventory change. Information passed through these networks differed from most of today's Internet information, in that it was structured or standardized. Members of the EDI network agreed on the forms that presents the data, and uses translation software to ensure that the transmitted data can be understood by their computer systems and that their records/inventory immediately updated.

An EDI message contains a string of data elements, each of which represents a singular fact, such as a price, product model number, and so forth, separated by delimiters. The entire string is called a data segment. One or more data segments framed by a header and trailer form a transaction set, which is the EDI unit of transmission (equivalent to a message). A transaction set often consists of what is contained in a typical business document or form. The parties who exchange EDI transmissions are referred to as trading partners.

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) mandates that health care organizations must adopt transaction and information security standards to support the electronic exchange of administrative and financial health care data for the purpose of administrative simplification. See the HIPAA Transaction Set Synopsis subsection below.

Three HIPAA adapters are available for use with Map Designer to help speed the creation, parsing, transformation, and integration of HIPAA transactions with existing systems. They provide built-in HIPAA transaction parsing logic, and compliant target templates for mapping native data (without the need to modify existing applications). The adapters provide a tool to develop and test transactions while maintaining data integrity.

The following schema files are included with map designer:

Document schemas for other HIPAA transaction sets can be purchased. Contact Sales for more information.

Here is a quick tip to determine whether you are working with valid HIPAA EDI files as the source. Check the value of the second record of the file. The value here should be something like "005010XNNN", where "NNN" is the numeric value corresponding to the appropriate HIPAA X-code transaction set (such as "005010X098" for the Professional 837).

For example:

A listing of HIPAA transaction sets, which includes Guide ID, Guide Description, Primary Trading Partners, and Exceptions/Limitations, follows:

GUIDE ID: 005010X092

Guide Description: The Health Care Eligibility/Benefit Inquiry and Information Response Implementation Guide describes the use of the Eligibility, Coverage or Benefit Inquiry (270) Version/Release 3070 transaction set and the Eligibility, Coverage, or Benefit Information (271) Version/Release 3070 transaction set for the following business usage:

PRIMARY TRADING PARTNERS: Health care providers, such as hospitals and physicians. Health care payers, such as insurance companies, HMOs, PPOs, and state and federal agencies, such as Medicare, Medicaid and CHAMPUS.

EXCEPTIONS/LIMITATIONS: Intended for use for health care eligibility/benefits. Does not provide a history of benefit usage. Is not intended for property and casualty or workers' compensation usage.

GUIDE ID: 005010X093

DESCRIPTION: The Health Care Claim Status Request and Response Implementation Guide describes the use of the ANSI ASC X12.316 Health Care Claim Status Request (276) transaction set and the ANSI ASC X12.317 Health Care Claim Status Notification (277) transaction set for the following business usage:

PRIMARY TRADING PARTNERS: Health care providers, such as hospitals, physicians, medical groups, independent physician associations, and facilities. Health care payers, such as insurance companies, HMO's, PPO's, and state and federal agencies.

When finalized, this document will be mentioned in an upcoming Notice of Proposed Rulemaking (NPRM)

GUIDE ID: 004020X094

DESCRIPTION: Describes the use of the ANSI ASC X12 Health Care Services Review Information (278) Version/Release 5010 transaction set for the following business usage:

PRIMARY TRADING PARTNERS: Health care providers, such as hospitals, physicians, medical groups, independent physician associations, and facilities. Health care review entities, such as insurance companies, HMOs, PPOs, health care purchasers, professional review organizations, and other utilization review organizations.

EXCEPTIONS/LIMITATIONS: Does not include health care services review for patient arrival, transfer, and discharge notices; certification change notices; and medical therapy supporting information.

GUIDE ID: 005010X061

DESCRIPTION: Describes the use of the ANSI ASC X12 Payment Order/Remittance Advice (820) transaction set, version 5010 for the following business usage:

This guide was also designed for health care premium payments between federal and state governments, government agencies, and private industry.

PRIMARY TRADING PARTNERS: Insurance companies Third-party administrators Payroll service providers Internal payroll departments.

EXCEPTIONS/LIMITATIONS: Does not support insurance claim payments and not intended for use in pension and investment type products.

GUIDE ID: 005010X095

DESCRIPTION: Describes the use of the ANSI ASC X12 Benefit Enrollment Maintenance (834) transaction set for the following business usage:

PRIMARY TRADING PARTNERS: The benefits process addressed in this guide involves the transmission of benefits information between group benefit plan sponsors and benefit plan administrators.

GUIDE ID: 005010X091

DESCRIPTION: Describes the use of the ANSI ASC X12 Health Care Claim Payment/Advice (835) transaction set for the following business usages:

PRIMARY TRADING PARTNERS: Health care providers such as hospitals and physicians; health care payers such as insurance companies, PPOs, HMOs, and state and federal agencies.

EXCEPTIONS/LIMITATIONS: Intended use is for health care remittance advice/payment. It is not intended for non-health care use.

GUIDE ID: 005010X097

DESCRIPTION: Describes the use of the ANSI ASC X12 Health Care Claim (837) transaction set for the following business usage:

PRIMARY TRADING PARTNERS: Health care providers, such as dentists and dental groups. Health care payers, such as private health care insurers and HMOs.

EXCEPTIONS/LIMITATIONS: Does not explicitly support property and casualty medical bill claims.

GUIDE ID: 005010X096

DESCRIPTION: Describes the use of the ANSI ASC X12 Health Care Claim (837) transaction set for the following business usage:

PRIMARY TRADING PARTNERS: Health care providers, such as clinics and hospitals. Health care payers, such as private insurers and federally-supported health care payers.

EXCEPTIONS/LIMITATIONS: Does not explicitly support property and casualty medical bill claims.

GUIDE ID: 005010X098

DESCRIPTION: Describes the use of the ANSI ASC X12 Health Care Claim (837) transaction set for the following business usage:

PRIMARY TRADING PARTNERS: Health care providers, such as physicians and surgeons. Health care payers, such as private health care insurers and HMOs.

Purpose: for trading of prescription information

Description: ASCII-based claim form. Precursor to HIPAA claims. This "standard" is a form for a physician encounter.

For more information, see the following web site:

997 (EDI): Functional Acknowledgement

Purpose: To start and identify an interchange of one or more functional groups.

Health Level Seven (HL7) is an organization that develops messaging standard specifications that enable disparate healthcare applications to exchange keys sets of clinical and administrative data. The HL7 standard provides an electronic interchange of clinical, financial and administrative information among independent healthcare-oriented computer systems, such as hospital information systems, clinical laboratory systems, enterprise systems and pharmacy systems.

"Level Seven" refers to the highest level of the International Standards Organization's (ISO) communications model for Open Systems Interconnection (OSI) - the application level. The application level addresses definition of the data to be exchanged, the timing of the interchange, and the communication of certain errors to the application. The seventh level supports such functions as security checks, participant identification, availability checks, exchange mechanism negotiations and, most importantly, data exchange structuring.

HL7 is singular as it focuses on the interface requirements of the entire health care organization, while most other efforts focus on the requirements of a particular department.

The HL7 governing body group works to comply with United States and International standards development activities. HL7 is an American National Standards Institute (ANSI) approved Standards Developing Organization (SDO).

The global influence of HL7 is evidenced in the number of countries that adhere to HL7 initiatives, including Argentina, Australia, Canada, China, Czech Republic, Finland, Germany, India, Japan, Korea, Lithuania, The Netherlands, New Zealand, Southern Africa, Switzerland, Taiwan, Turkey and the United Kingdom.

The HL7 standard provides the layout of messages exchanged between two or more applications. A message is comprised of multiple segments that must be sent in a particular order and which may or may not repeat. Segments are collections of data elements that typically share a common subject. For example, the PID segment contains patient identification data elements such as name, address and social security number. The NK1 next of kin segment contains similar data elements about the patient's next of kin.

HL7 defines which data elements are to be sent, and determines the data type and the suggested length of each. It also indicates whether the data element is required or optional, and whether it may repeat. Fields must be sent in the order in which they are presented in the Standard. This way, both the sending and receiving systems know what data is expected, in what order, and in what format. HL7 also enables one system to query another for relevant information.

Document Schema Designer currently supports HL7 version 2.3.1.

At first glance, HL7 data looks nearly identical to EDI data. But there are significant differences. HL7 data contains:

EDI, or Electronic Data Interchange, uses standard formats to pass data between the disparate business systems. Third parties provide EDI services that enable organizations with different equipment to connect. Although interactive access may be a part of it, EDI implies direct computer-to-computer transactions into vendors' databases and ordering systems. The EDI standard is ANSI X12, developed by the Data Interchange Standards Association (DISA). ANSI X12 is either closely coordinated with or is being merged with an international standard, EDIFACT.

An EDI message contains a string of data elements, each of which represents a singular fact, such as a price, product model number, and so forth, separated by delimiters. The entire string is called a data segment. One or more data segments framed by a header and trailer form a transaction set, which is the EDI unit of transmission (equivalent to a message). A transaction set often consists of what would usually be contained in a typical business document or form. The parties who exchange EDI transmissions are referred to as trading partners.

Society for Worldwide Interbank Financial Telecommunication (SWIFT) message type is the format or schema used to send messages to financial institutions on a secure SWIFT network. The data exchanged between institutions is unambiguous and machine friendly, facilitating automation, reducing costs and mitigating risks.

SWIFT messages consist of five blocks of the data including three headers, message content, and a trailer.